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. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
