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
In response to
pgsql-hackers by date
|Next:||From: David Lee Lambert||Date: 2008-12-24 18:08:01|
|Subject: Re: uuids on freebsd|
|Previous:||From: Tom Lane||Date: 2008-12-24 16:16:33|
|Subject: Re: generic reloptions improvement |