From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
cc: Joe Carlson <jwcarlson@lbl.gov>, pgsql-performance@postgresql.org
Subject: Re: Row level security policy policy versus SQL constraints. Any
 performance difference?
In-reply-to: <993c32d2-1389-66aa-1368-ca44de370a3a@2ndquadrant.com>
References: <59E66BA8.6060009@lbl.gov>
 <993c32d2-1389-66aa-1368-ca44de370a3a@2ndquadrant.com>
Comments: In-reply-to Tomas Vondra <tomas.vondra@2ndquadrant.com>
	message dated "Tue, 17 Oct 2017 23:35:58 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14729.1508278004.1@sss.pgh.pa.us>
Date: Tue, 17 Oct 2017 18:06:44 -0400
Message-ID: <14730.1508278004@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On 10/17/2017 10:44 PM, Joe Carlson wrote:
>> What I was wondering is what is the performance differences between a
>> row level security implementation:
>> ...
>> and an implementation where I add on the constraints as part of each
>> select statement:

> The main point of the RLS is enforcing an order in which the conditions
> are evaluated.

Yeah.  Because of that, I would *not* recommend RLS if you can equally
well stick the equivalent conditions into your queries.  There is way
too much risk of taking a serious performance hit due to a bad plan.

An alternative you might consider, if simplifying the input queries
is useful, is to put the fixed conditions into a view and query the
view instead.  That way there's not an enforced evaluation order.

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance