"Simon Riggs" <simon@2ndquadrant.com> writes:
> I've just read a paper that says PostgreSQL doesn't do this.
What does he mean by that exactly, and which PG version is he looking
at? As Greg notes, we do know how to push down non-aggregated
conditions, but I'm not sure that's what he's thinking of. There have
been some relevant bug fixes, eg
2004-07-10 14:39 tgl
* src/backend/executor/: nodeAgg.c (REL7_4_STABLE), nodeAgg.c: TestHAVING condition before computing targetlist of an
Aggregatenode. This is required by SQL spec to avoid failures in cases like SELECT sum(win)/sum(lose) FROM ... GROUP
BY... HAVING sum(lose) >0; AFAICT we have gotten this wrong since day one. Kudos to HolgerJakobs for being the first
tonotice.
Also, it's still true that we run all the aggregate transition functions
in parallel, so if you were hoping to use HAVING on an aggregate
condition to prevent an overflow or something in the state accumulation
function for a targetlist aggregate, you'd lose. But I don't see any
way to avoid that without scanning the data twice, which we're surely
not gonna do.
regards, tom lane