For EXISTS SubLink, in some cases the subquery can be reduced to constant TRUE or FALSE, based on the knowledge that it's being used in EXISTS(). One such case is when the subquery has aggregates without GROUP BY or HAVING, and we know its result is exactly one row, unless that row is discarded by LIMIT/OFFSET. (Greenplum does this.)
Is it worthwhile to add some codes for such optimization? If so, I can
try to propose a patch
While the examples clearly demonstrate what you are saying they don’t provide any motivation to do anything about it - adding aggregates and offset to an exists subquery seems like poor query design that should be fixed by the query writer not by spending hacker cycles optimizing it.
Thanks David. I have the same concern that this case is not common
