On 2017-10-16 11:12:09 -0400, Tom Lane wrote: > 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.
Thanks, that looks like a reasonable fix. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers