Re: Various performance questions
От | Tom Lane |
---|---|
Тема | Re: Various performance questions |
Дата | |
Msg-id | 1735.1067280732@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Various performance questions (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: Various performance questions
Re: Various performance questions |
Список | pgsql-performance |
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
В списке pgsql-performance по дате отправления: