Heikki Linnakangas <hlinnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
