Re: Aggregate transition state merging vs. hypothetical set functions
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-10-12T23:58:17Z
Lists: pgsql-hackers
On 13 October 2017 at 12:41, Tom Lane <tgl@sss.pgh.pa.us> wrote: > David Rowley <david.rowley@2ndquadrant.com> writes: >> If the user defines their normal aggregate as not safe for merging, >> then surely it'll not be suitable to be used as a window function >> either, since the final function will also be called there multiple >> times per state. > > Yeah, we would probably also want to check the flag in nodeWindowAgg. > Not sure exactly how that should play out --- maybe we end up with > a tri-valued property "works as normal agg without merging, works > as normal agg with merging, works as window agg". But this would > arguably be an improvement over the current situation. Right now > I'm sure there are user-written aggs out there that will just crash > if used as a window agg, and the authors don't have much choice because > the performance costs of not modifying the transition state in the > finalfn are higher than they're willing to bear. At least with a > flag they could ensure that the case will fail cleanly. hmm, maybe I'm lacking imagination here, but surely the final function is either destructive or it's not? I can't understand what the difference between nodeAgg.c calling the finalfn multiple times on the same state and nodeWindowAgg.c doing it. Maybe there's something I'm not accounting for that you are? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Improve spelling of new FINALFUNC_MODIFY aggregate attribute.
- f755a152d4e3 11.0 landed
-
Explicitly track whether aggregate final functions modify transition state.
- 4de2d4fba38f 11.0 landed