Neil Conway <neilc@samurai.com> writes:
> On Thu, 2004-12-02 at 10:45 -0500, Tom Lane wrote:
>> (2) I think you lose much of the performance
>> benefit as soon as you have to distinguish cases (b) and (c).
> Why wouldn't a simple comparison work? We're passing two arguments into
> the aggregate function: (a) corresponds to returning the first argument,
> and (b) corresponds to returning the second argument.
True, but you still have to palloc if it returns the second argument.
> Yeah, I like your approach as well (sorry, I had thought Simon's earlier
> suggestion along these lines would have required adding knowledge about
> builtin aggregates to advance_transition_function() itself; adding
> knowledge to the aggregate implementation is a lot nicer).
It needs documentation --- what I sent you was just a crude hack for
testing, not something I would've committed as-is. IIRC, the spec I had
in mind was "if fcinfo->context is an AggState node then the function
may assume it's being called as an aggregate's transition or final
function. In this case, the first argument is certainly either an
initial value or the output of a prior transition function call. The
function may assume that it's OK to scribble on the first argument
instead of allocating a fresh object for its result." One could also
imagine that the transition and final functions could make a private
agreement about the contents of the state value, such that it needn't
be a strictly valid Datum --- for instance it might contain pointers to
additional transient storage someplace. I think that at the time we
were discussing such hacks in connection with user-defined aggregates
that needed a large amount of state.
regards, tom lane
