Gregory Stark <st...@enterprisedb.com> writes:
> Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
