Re: Row level security performance joining large tables

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: "David R(dot) Pike" <david(dot)pike(at)trustedconcepts(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Row level security performance joining large tables
Date: 2016-11-10 14:50:31
Message-ID: 20161110145031.GG13284@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

David,

* David R. Pike (david(dot)pike(at)trustedconcepts(dot)com) wrote:
> From what I can understand the RLS implementation strives to execute policy checks before user provided predicate checks so as to avoid leaking protected data. Is there any way to make the join look "safe" to the optimizer to avoid full table scans? Isn't this a common scenario?

You can use a security barrier view which is owned by the same user that
the tables underneath are owned by, that will bypass RLS on the tables
themselves and therefore you'll need to implement the appropriate quals
in the security barrier view.

As Tom mentions, we're working to improve RLS optimization as well. As
is pretty common with various features, the initial implementation
provides the functionality but perhaps isn't as performant as one might
like, and then we iterate and improve it in the subsequent releases.

Thanks!

Stephen

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2016-11-10 15:11:12 Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists
Previous Message Adrian Klaver 2016-11-10 14:40:43 Re: Postgresql 94 from PostgreSQL RPM Repository (with Yum)