Florian Pflug <fgp@phlo.org> writes:
> I still think you're getting ahead of yourselves here. The number of
> aggregates which benefit from this is tiny SUM(int2,int4) and maybe
> BOOL_{AND,OR}. And in the SUM(int2,int4) case *only* on 64-bit archs -
> for the others, the state type is already pass-by-ref.
That argument is reasonable for the initfunc idea, but it doesn't apply
otherwise.
> Another reason I'm so opposed to this is that inverse transition
> functions might not be the last kind of transition functions we ever
> add. For example, if we ever get ROLLUP/CUBE, we might want to have
> a mergefunc which takes two aggregation states and combines them
> into one. What do we do if we add those?
Make more pg_aggregate columns. What exactly do you think is either
easier or harder about such cases? Also, maybe I'm misremembering
the spec, but ROLLUP/CUBE wouldn't apply to window functions would
they? So if your argument is based on the assumption that these
features need to combine, I'm not sure it's true.
The bottom line for me is that it seems conceptually far cleaner to
make the moving-aggregate support be independent than to insist that
it share an stype and sfunc with the plain case.
Furthermore, I do not buy the argument that if we hack hard enough,
we can make the performance cost of forcing the sfunc to do double duty
negligible. In the first place, that argument is unsupported by much
evidence, and in the second place, it will certainly cost us complexity
to make the performance issue go away. Instead we can just design the
problem out, for nothing that I see as a serious drawback.
regards, tom lane