On Thu, 2008-11-13 at 10:44 +0900, KaiGai Kohei wrote:
> It's unclear for me what is the point you said.
> I guess you concern the fixed length field is always allocated in
> the case when any security feature is not enabled also, or performance
> degradation on the large scale databases.
> If incorrect, please tell me in another expression.
>
> At first, the fixed length 4 byte field is allocated only when
> the SE-PostgreSQL (or other security feature) is enabled. It can be
> controlled via PGACE hook. The pgaceSecurityAttributeNecessary() can
> return bool value, and it indicates the necessity of the security
> field. If SE-PostgreSQL is disabled on compile-time or run-time,
> the fixed length 4 byte value is not allocated.
I'm sorry for not making my thoughts clearer. Let me try again:
As I understand it, when enabled, the overhead for each row is more than
4 bytes because you include a text field also, which you say has a
restricted number of values. IMHO the overhead is unacceptable, given
that our row overhead is already high. I would prefer to make the
maximum overhead per row 4 bytes only, which matches the maximum number
of required labels. This will allow very large databases to use this
feature.
I would also like to see the feature part of normal Postgres, rather
than as a compile time option. The per-row overhead would then be
optional, just as WITH OIDS is optional. This would allow many
applications to take advantage of row level security, without the need
for switching to a different executable and without the need to enable
it for every table. For high security applications, default_row_security
= on would obviously be a requirement. With a single executable on all
distros we will have more robust software and it will be easier to
configure and use.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support