On 2011-07-21 00:08, Robert Haas wrote:
On Wed, Jul 20, 2011 at 4:48 PM, Tom Lane<t...@sss.pgh.pa.us> wrote:
Kohei Kaigai<kohei.kai...@emea.nec.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.
I agree that we don't want to limit the size of the catcaches. We've
been careful to design them in such a way that they won't blow out
memory, and so far there's no evidence that they do. If it ain't
broke, don't fix it. Having catcaches that can grow in size as needed
sounds useful to me, though.
Is there a way to dump syscache statistics like there is for
MemoryContext..Stats (something - gdb helped me there)?
Besides that I have to admit having problems understanding why the 5MB
cache for pg_seclabel is a problem; it's memory consumption is lineair
only to the size of the underlying database. (in contrast with the
other cache storing access vectors which would have O(n*m) space
complexity if it wouldn't reclaim space). So it is proportional to the
number of objects in a database and in size it seems to be in the same
order as pg_proc, pg_class and pg_attribute.
regards,
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
