public inbox for [email protected]  
help / color / mirror / Atom feed
From: Jason Borg <[email protected]>
To: [email protected] <[email protected]>
Subject: Row-level security performance
Date: Tue, 24 Oct 2017 02:51:26 +0000
Message-ID: <MEXPR01MB1334F05EE1638E9188A9E69094470@MEXPR01MB1334.ausprd01.prod.outlook.com> (raw)
List-Unsubscribe:  <mailto:[email protected]?body=unsub%20pgsql-performance>

Hi,

I see in the v10 release notes (2017-10-05) that there's been a change to "Improve performance of queries affected by row-level security restrictions". I am using RLS in a Postgres 9.5 database and am seeing some very bad performance when joining tables. Upgrading this DB to v10 shows a huge performance increase in some cases where RLS has proven to be an issue, but not all.

I see here (https://www.postgresql.org/message-id/14730.1508278004%40sss.pgh.pa.us), that Tom Lane (author of the commit for the aforementioned release note) remarked on 2017-10-17: "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."

What's the current advice, and future plans for row-level security performance optimisations?
Though things have improved in v10, is there likely to always be that risk of a bad plan arising?

Regards,
Jason Borg.


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




reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected]
  Subject: Re: Row-level security performance
  In-Reply-To: <MEXPR01MB1334F05EE1638E9188A9E69094470@MEXPR01MB1334.ausprd01.prod.outlook.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox