I wrote: > I think possibly the best answer is to revert 8ed3f11bb. We could > think about some compromise solution like merging the projections > only for aggregates without FILTER. But that would require two > code paths through the relevant functions in nodeAgg.c, which would > be a substantial maintenance burden; and the extra branches required > means that this would be a net negative for performance in the > simplest case with only one aggregate.
Hmm ... on closer inspection, the only performance-critical place where this matters is advance_aggregates, and that already has a check for whether the particular aggregate has a filter. So we could do something like /* Skip anything FILTERed out */ if (filter) { // existing code to eval/check filter expr + + /* Now it's safe to evaluate this agg's arguments */ + slot = ExecProject(pertrans->argproj); } + else + slot = aggstate->evalslot; which seems like a pretty minimal extra cost for the normal case with no filter. Let me see what I can make of that ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers