Re: Aggregate transition state merging vs. hypothetical set functions

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-10-13T00:12:51Z
Lists: pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> On 13 October 2017 at 12:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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".

> 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?

nodeWindowAgg is doing something more: not only is it calling the finalfn
repeatedly, but it's continuing to mutate the transition state in between.
The ordered-set aggs provide a counterexample to considering that to be
equivalent to state merging.  The OSAs can cope with state merging as
long as they have a flag to make sure only the first finalfn does
tuplesort_performsort ... but that's not good enough to make them workable
as window aggs.  Once we sort, we can't absorb more rows into the
tuplesort object.

			regards, tom lane


Commits

  1. Improve spelling of new FINALFUNC_MODIFY aggregate attribute.

  2. Explicitly track whether aggregate final functions modify transition state.