Re: API change advice: Passing plan invalidation info from the rewriter into the planner?

On Wed, Jun 18, 2014 at 2:18 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> I'm also of the opinion that this isn't strictly necessary for the
> initial RLS offering in PG- there's a clear way we could migrate
> existing users to a multi-policy system from a single-policy system.
> Sure, to get the performance and optimization benefits that we'd
> presumably have in the multi-policy case they'd need to re-work their
> RLS configuration, but for users who care, they'll likely be very happy
> to do so to gain those benefits.

I think a lot depends on the syntax we choose. If we choose a syntax
that only makes sense in a single-policy framework, then I think
allowing upgrades to a multi-policy syntax is going to be really
difficult. On the other hand, if we choose a syntax that allows
multiple policies, I suspect we can support multiple policies from the
beginning without much extra effort.

>> - Require the user to specify in some way which of the available
>> policies they want applied, and then apply only that one.
>
> I'd want to at least see a way to apply an ordering to the policies
> being applied, or have PG work out which one is "cheapest" and try that
> one first.

Cost-based comparison of policies that return different results
doesn't seem sensible to me.

>> I think exactly the opposite, for the query planning reasons
>> previously stated. I think the policies will quickly get so
>> complicated that they're no longer optimizable. Here's a simple
>> example:
>>
>> - Policy 1 allows the user to access rows for which complexfunc() returns true.
>> - Policy 2 allows the user to access rows for which a = 1.
>>
>> Most users have access only through policy 2, but some have access
>> through policy 1. Users who have access through policy 1 will always
>> get a sequential scan,
>
> This is the thing which I most object to- if the quals being provided at
> any level are leakproof and would be able to reduce the returned set
> sufficiently that an index scan is the best bet, we should be doing
> that. I don't anticipate the RLS quals to be as selective as the
> quals which the user is adding.

I think it would be a VERY bad idea to design the system around the
assumption that the RLS quals will be much more or less selective than
the user-supplied quals. That's going to be different in different
environments.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company