On 2011-07-21 15:03, Robert Haas wrote:
On Thu, Jul 21, 2011 at 4:00 AM, Yeb Havinga<yebhavi...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
