Re: [v9.1] sepgsql - userspace access vector cache - Mailing list pgsql-hackers

From Yeb Havinga
Subject Re: [v9.1] sepgsql - userspace access vector cache
Date
Msg-id 4E287D21.9000600@gmail.com
Whole thread Raw
In response to Re: [v9.1] sepgsql - userspace access vector cache  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [v9.1] sepgsql - userspace access vector cache
Re: [v9.1] sepgsql - userspace access vector cache
List pgsql-hackers
On 2011-07-21 15:03, Robert Haas wrote:
> On Thu, Jul 21, 2011 at 4:00 AM, Yeb Havinga<yebhavinga@gmail.com>  wrote:
>> 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.
> Fair enough.  I'm not convinced that the sheer quantity of memory use
> is a problem, although I would like to see a few more test results
> before we decide that definitively.  I *am* unwilling to pay the
> startup overhead of initializing an extra 2048 syscache that only
> sepgsql users will actually need.

Is it possible to only include the syscache on --enable-selinux 
configurations? It would imply physical data incompatibility with 
standard configurations, but that's also true for e.g. the block size.

Also, the tests I did with varying bucket sizes suggested that 
decreasing the syscache to 256 didn't show a significant performance 
decrease compared to the 2048 #buckets, for the restorecon test, which 
hits over 3000 objects with security labels. My guess is that that is a 
fair middle of the road database schema size. Are you unwilling to pay 
the startup overhead for a extra 256 syscache?

-- 

Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data



pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: sinval synchronization considered harmful
Next
From: Robert Haas
Date:
Subject: Re: sinval synchronization considered harmful