Thanks for your suggestions.
I had pretty much given up on this idea. At first, I had thought there
would only be 2 or 3 different constraint cases to consider. I had
thought of using distinct credentials for my connection and using RLS to
give different cuts on the same table. The different policies could be
established in advance and never touched.
But then it became clear that I actually would need a very large number
of different restrictions on the tables - too many to create in advance.
At this point it's easiest to apply constraints on each select rather
than apply a policy every time.
Thanks,
Joe
On 10/17/2017 03:06 PM, Tom Lane wrote:
Tomas Vondra <tomas.von...@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
