From: | tgl(at)postgresql(dot)org (Tom Lane) |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Remove the limit on the number of entries allowed in catcaches, |
Date: | 2006-06-15 02:08:09 |
Message-ID: | 20060615020809.B52E79FA4A8@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Log Message:
-----------
Remove the limit on the number of entries allowed in catcaches, and
remove the infrastructure needed to enforce the limit, ie, the global
LRU list of cache entries. On small-to-middling databases this wins
because maintaining the LRU list is a waste of time. On large databases
this wins because it's better to keep more cache entries (we assume
such users can afford to use some more per-backend memory than was
contemplated in the Berkeley-era catcache design). This provides a
noticeable improvement in the speed of psql \d on a 10000-table
database, though it doesn't make it instantaneous.
While at it, use per-catcache settings for the number of hash buckets
per catcache, rather than the former one-size-fits-all value. It's a
bit silly to be using the same number of hash buckets for, eg, pg_am
and pg_attribute. The specific values I used might need some tuning,
but they seem to be in the right ballpark based on CATCACHE_STATS
results from the standard regression tests.
Modified Files:
--------------
pgsql/src/backend/utils/cache:
catcache.c (r1.128 -> r1.129)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/catcache.c.diff?r1=1.128&r2=1.129)
syscache.c (r1.103 -> r1.104)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/syscache.c.diff?r1=1.103&r2=1.104)
pgsql/src/include/utils:
catcache.h (r1.58 -> r1.59)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/catcache.h.diff?r1=1.58&r2=1.59)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-06-15 02:23:14 | pgsql: Done, removed: < < * Consider padding the spinlock structure to |
Previous Message | Tom Lane | 2006-06-14 23:54:35 | Re: pgsql: Got tired of waiting for spoonbill's compiler |
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2006-06-15 02:14:26 | Re: Spinlocks, yet again: analysis and proposed patches |
Previous Message | John Hansen | 2006-06-15 02:04:21 | Re: archive threads across months (was Re: [HACKERS] |