Greg Stark <gsstark@mit.edu> writes:
> On Mon, Nov 9, 2009 at 3:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That requires that you know how to copy the aggregate's state. �You do
>> not. �(In some cases the aggregate function has extra state besides the
>> nominal transition datum...)
> That's relatively unusual and usually a bad idea, imho. We could add a
> flag to indicate whether that's the case and only do the optimization
> if it's not set. It would rarely be set.
We already burned that bridge, unfortunately --- core and contrib both
contain examples of aggregates that do things this way, and I'll bet
there are third-party examples by now. If you have a large working
state for an aggregate, it's just too tempting to prevent nodeAgg.c
from copying the darn thing all the time.
It's fairly clear that efficient support for this will require extra
help from the aggregate author. Ideally we would define it so that
the author could implement it either with negative transitions or with
multiple copies of the agg state, whichever seems most efficient.
The cases that are hard are exactly where the agg state is large,
so I doubt it's a good idea to legislate that multiple copies is how
to do it.
In any case, I don't think we can put retroactive restrictions on what
the aggregates do in the normal case, and we can definitely not assume
that existing aggregates will politely tell us what they are doing.
regards, tom lane