Re: Window-functions patch handling of aggregates

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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