2008/12/25 Tom Lane <tgl@sss.pgh.pa.us>:
> 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...
I have concerned it once before on the first design of the window
functions. I don't have much idea about all over the aggregate
functions but at least count(*) does some assumption of AggState in
its context. So I concluded when the window functions are introduced
it must be announced that if you use aggregate in the window context,
you must be sure it supports window as well as aggregate. It is
because currently (<= 8.3) aggregates are assumed it is called in
AggState only but the assumption would be broken now. It is designed,
and announcing helps much third party code to support or not to
support window functions (i.e. you can stop by error if window is not
supported by the function).
Regards,
--
Hitoshi Harada