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. +
