Horton

Re: 8.4 release planning

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Joshua Brindle <method@manicmethod.com>, Ron Mayer <rm_pg@cheapcomplexdevices.com>, Josh Berkus <josh@agliodbs.com>, "Joshua D. Drake" <jd@commandprompt.com>, Merlin Moncure <mmoncure@gmail.com>, "Jonah H. Harris" <jonah.harris@gmail.com>, Gregory Stark <stark@enterprisedb.com>, Bruce Momjian <bruce@momjian.us>, Bernd Helmle <mailings@oopsware.de>, Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Date: 2009-01-27T17:52:41Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jan 27, 2009 at 11:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It would prevent us from making optimizations that assume foreign key
>> constraints hold; which is a performance issue not a covert-channel
>> issue.

> Oh, I see now.  That problem is going to be common to row-level DAC
> and SE-PostgreSQL proper.  It would not surprise me if any sort of
> row-level access control turns out to be bad for performance, but
> mainly because the overhead of checking permissions on every tuple is
> bound to cost something.

Right, but you expect that to be a small and predictable cost, say in
the single-digits-percentage range.  Plan optimizations that
suddenly stop happening can cost you multiple orders of magnitude.
And you won't soothe people by telling them that obsolete versions of
Postgres would have been that slow all the time.

			regards, tom lane