Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I am thinking we should scale it based on max_fsm_relations.
Hmm ... tables are not the only factor in the required catcache size,
and max_fsm_relations tells more about the total installation size
than the number of tables in your particular database. But it's one
possible approach.

I just thought of a more radical idea: do we need a limit on catcache
size at all? On "normal size" databases I believe that we never hit
5000 entries at all (at least, last time I ran the CATCACHE_STATS code
on the regression tests, we didn't get close to that). We don't have
any comparable limit in the relcache and it doesn't seem to hurt us,
even though a relcache entry is a pretty heavyweight object.

If we didn't try to enforce a limit on catcache size, we could get rid
of the catcache LRU lists entirely, which'd make for a nice savings in
lookup overhead (the MoveToFront operations in catcache.c are a
nontrivial part of SearchSysCache according to profiling I've done,
so getting rid of one of the two would be nice).
Well, assuming you never access all those tables, you don't use lots of
memory, but if you are accessing a lot, it seems memory for all your
tables is a minimal overhead.

Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 8 | next ›
Discussion Overview
grouppgsql-hackers @
postedJun 14, '06 at 11:25p
activeJun 15, '06 at 1:32p



site design / logo © 2018 Grokbase