Skip site navigation (1) Skip section navigation (2)

Re: Various performance questions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Dror Matalon <dror(at)zapatec(dot)com>,PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Various performance questions
Date: 2003-10-27 18:52:12
Message-ID: 1735.1067280732@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Neil Conway <neilc(at)samurai(dot)com> writes:
> On Mon, 2003-10-27 at 12:56, Greg Stark wrote:
>> Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

pgsql-performance by date

Next:From: Neil ConwayDate: 2003-10-27 18:54:50
Subject: Re: Various performance questions
Previous:From: Neil ConwayDate: 2003-10-27 18:40:06
Subject: Re: Various performance questions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group