Re: Window-functions patch handling of aggregates

Gregory Stark <stark@enterprisedb.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Unless we want to move the goalposts on what an aggregate is allowed
>> to do internally, we're going to have to change this to re-aggregate
>> repeatedly.  Neither prospect is appetizing in the least.

> Does it currently copy the state datum before calling the final function?
> Would that help?

No.  The entire point of what we have now formalized as "aggregates with
internal-type transition values" is that the transition value isn't
necessarily a single palloc chunk.  For stuff like array_agg, the
performance costs of requiring that are enormous.

On looking at what array_agg does, it seems the issue there is that
the final-function actually deletes the working state when it thinks
it's done with it (see construct_md_array).   It would probably be
possible to fix things so that it doesn't do that when it's called by
a WindowAgg instead of a regular Agg.  What I'm more concerned about
is what third-party code will break.  contrib/intagg has done this
type of thing since forever, and I'm sure people have copied that...
        regards, tom lane