Re: Analysis on backend-private memory usage (and a patch) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Analysis on backend-private memory usage (and a patch)
Date
Msg-id 12587.1378328209@sss.pgh.pa.us
Whole thread Raw
In response to Analysis on backend-private memory usage (and a patch)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Analysis on backend-private memory usage (and a patch)
List pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> One fairly simple thing we could do is to teach catcache.c to resize the 
> caches. Then we could make the initial size of all the syscaches much 
> smaller.

I think this is attractive for the *other* reason you mention, namely
preserving reasonable performance when a catcache grows larger than
expected; but I'm pretty skeptical of nickel-and-diming caches that are
already really small.  Is it really worth cutting the TSPARSER caches
from 4 pointers to 2 for instance?

What concerns me about initially-undersized caches is that we'll waste
space and time in the enlargement process.  I'd suggest trying to get some
numbers about the typical size of each cache in a backend that's done a
few things (not merely started up --- we should not be optimizing for the
case of connections that get abandoned without running any queries).
Then set the initial size to the next larger power of 2.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [rfc] overhauling pgstat.stat
Next
From: Bruce Momjian
Date:
Subject: Re: [PERFORM] encouraging index-only scans