Simon Riggs wrote:
> The only remaining problem for me now is the size of the security
> context column added to each row. I can accept a fixed length 4 byte
> value, but anything longer just seems that it will render this unusable.
> Normal apps should be able to benefit from row level security, as well
> as high-security apps. The additional row overhead is enough to prevent
> that, as well as put off many very large high security apps - which is
> catastrophic because many of them are very large these days.
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.
In the next, we assumes the users of SE-PostgreSQL don't give its
performance the first priority. However, the past measurement shows
its cost is far from the representation of "catastrophic".
The following article shows the result of pgbench at the 8.4devel
with rivision 1063.
http://kaigai.sblo.jp/article/20303941.html
It shows 8% of degradation in the worst cases, and it has a trend
that larger scale database has smaller degradation.
(The measurement is same as I introduced a month ago.)
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
