Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jan 27, 2009 at 12:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
> Well, look at it another way. If we don't accept row-level security
> into PostgreSQL, then people will have to implement it themselves. In
> fact, I currently have a real application that does exactly this. The
> row-filtering is done, in essence, by having the web application add
> certain conditions to the WHERE clause of certain queries depending on
> which user is making the request. And if those WHERE clauses happen
> to mention columns from table X, then table X won't be a candidate for
> join removal. The only difference is that the logic is in my app
> rather than in the database itself.
> To put that another way, row-level permissions are just another
> attribute of a table that could potentially affect the query result,
> and the impact of referring to that attribute will be exactly the same
> as the impact of referring to any other attribute in that table.
The flaw in that argument is that as you are doing it, the
de-optimization only happens on queries that actually need the behavior.
As the SEPostgres patch is constructed, the planner could *never* trust
an FK for optimization since it would have no way to know whether row
level permissions might be present (perhaps only for some rows) at
execution time. You could only get back the optimization in builds with
SEPostgres compiled out. That's pretty nasty, especially for packagers
who have to decide which build setting will displease fewer users.
regards, tom lane