Re: [v9.1] sepgsql - userspace access vector cache

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