Neil Conway <neilc@samurai.com> writes:
> On Mon, 2003-10-27 at 12:56, Greg Stark wrote:
>> Neil Conway <neilc@samurai.com> writes:
>>> Uh, what? Why would an int8 need to be "dynamically allocated
>>> repeatedly"?
>>
>> Perhaps I'm wrong, I'm extrapolating from a comment Tom Lane made that
>> profiling showed that the bulk of the cost in count() went to allocating
>> int8s. He commented that this could be optimized by having count() and sum()
>> bypass the regular api. I don't have the original message handy.
> I'm still confused: int64 should be stack-allocated, AFAICS. Tom, do you
> recall what the issue here is?
Greg is correct. int8 is a pass-by-reference datatype and so every
aggregate state-transition function cycle requires at least one palloc
(to return the function result). I think in the current state of the
code it requires two pallocs :-(, because we can't trust the transition
function to palloc its result in the right context without palloc'ing
leaked junk in that context, so an extra palloc is needed to copy the
result Datum into a longer-lived context than we call the function in.
There was some speculation a few weeks ago about devising a way to let
performance-critical transition functions avoid the excess palloc's by
working with a specialized API instead of the standard function call
API, but I think it'll have to wait for 7.5.
regards, tom lane
