I am thinking we should scale it based on max_fsm_relations.

---------------------------------------------------------------------------

Tom Lane wrote:
> Awhile back, there was a discussion about psql \d display being really
> slow in a database with 4000 tables:
> http://archives.postgresql.org/pgsql-hackers/2005-09/msg01085.php
> 
> I looked into this some, and it seems that part of the problem is that
> the catalog caches are limited to hold no more than 5000 tuples in total
> (MAXCCTUPLES in catcache.c).  When you're looking at thousands of
> tables, the tuples you want age out of cache immediately and so every
> SearchSysCache call has to actually go to disk (or at least shared
> buffers).
> 
> The 5000 setting is basically Berkeley-era (when we got the code from
> Berkeley, the limit was 300 tuples per cache, which I changed to a
> system-wide limit some years ago).  A reasonable guess is that we're
> talking about entries of 100 to 200 bytes each, making the maximum
> catcache space usage a megabyte or less (per backend, that is).  Seems
> like this is mighty small on modern machines.
> 
> We could make a GUC variable to control this, or just arbitrarily bump
> up the constant to 50000 or so.  Is it worth another GUC?  Not sure.
> 
> There's another hardwired setting right next to this one, which is the
> number of hash buckets per catcache.   Since the caches are likely to
> have significantly different sizes, that is looking a bit obsolete too.
> We could put per-cache numbers into the setup lists in syscache.c
> easily.  Making the cache sizes dynamic a la dynahash.c is another
> possibility, but I'm unsure if it's worth the trouble.
> 
> Thoughts?
> 
>                       regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
> 

-- 
  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 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to