On 2011-07-21 00:08, Robert Haas wrote:
> On Wed, Jul 20, 2011 at 4:48 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> Kohei Kaigai<Kohei.Kaigai@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