On Wed, Nov 24, 2010 at 3:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Full results, and call graph, attached. The first obvious fact is
>> that most of the memset overhead appears to be coming from
>> InitCatCache.
>
> AFAICT that must be the palloc0 calls that are zeroing out (mostly)
> the hash bucket headers. I don't see any real way to make that cheaper
> other than to cut the initial sizes of the hash tables (and add support
> for expanding them later, which is lacking in catcache ATM). Not
> convinced that that creates any net savings --- it might just save
> some cycles at startup in exchange for more cycles later, in typical
> backend usage.
>
> Making those hashtables expansible wouldn't be a bad thing in itself,
> mind you.
The idea I had was to go the other way and say, hey, if these hash
tables can't be expanded anyway, let's put them on the BSS instead of
heap-allocating them. Any new pages we request from the OS will be
zeroed anyway, but with palloc we then have to re-zero the allocated
block anyway because palloc can return a memory that's been used,
freed, and reused. However, for anything that only needs to be
allocated once and never freed, and whose size can be known at compile
time, that's not an issue.
In fact, it wouldn't be that hard to relax the "known at compile time"
constraint either. We could just declare:
char lotsa_zero_bytes[NUM_ZERO_BYTES_WE_NEED];
...and then peel off chunks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company