From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kohei Kaigai <Kohei(dot)Kaigai(at)EMEA(dot)NEC(dot)COM> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.1] sepgsql - userspace access vector cache |
Date: | 2011-07-20 20:48:29 |
Message-ID: | 20251.1311194909@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kohei Kaigai <Kohei(dot)Kaigai(at)EMEA(dot)NEC(dot)COM> writes:
> I'd like to have a discussion about syscache towards next commit-fest.
> The issues may be:
> - Initial bucket allocation on most cases never be referenced.
> - Reclaim cache entries on growing up too large.
There used to be support for limiting the number of entries in a
syscache. It got removed (cf commit
8b9bc234ad43dfa788bde40ebf12e94f16556b7f) because (1) it was remarkably
expensive to do it (extra list manipulations, etc), and (2) performance
tended to fall off a cliff as soon as you had a few more tables or
whatever than the caches would hold. I'm disinclined to reverse that
decision. It appears to me that the security label stuff needs a
different set of performance tradeoffs than the rest of the catalogs,
which means it probably ought to do its own caching, rather than trying
to talk us into pessimizing the other catalogs for seclabel's benefit.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-07-20 21:35:00 | Re: Commitfest Status: Sudden Death Overtime |
Previous Message | Bruce Momjian | 2011-07-20 20:47:50 | Re: A few user-level questions on Streaming Replication and pg_upgrade |