Re: Fwd: row level security (RLS) - Mailing list pgsql-general

From Rafal Pietrak
Subject Re: Fwd: row level security (RLS)
Date
Msg-id 52abbd1c-6d4f-6de0-1456-43ad81bcbfad@ztk-rp.eu
Whole thread Raw
List pgsql-general

W dniu 15.03.2021 o 18:01, Laurenz Albe pisze:
> On Mon, 2021-03-15 at 16:28 +0100, Rafal Pietrak wrote:
>> 5. My experiments with RLS was like following:
>>         - I've implemented a STABLE function, that returns INTEGER 1/0
>>         - I've linked that function as POLICY to my tables
>>         - I've GRANTED PUBLIC access to those tables
>>         ---> and all works as predicted.... only slow (10x slower!).
>>
>> [lots of questions about how to solve this is some other way]
>>
>> Those questions come from my bad experience with POLICY performance.
> 
> You should figure out why RLS was so slow.

Yes I should... although I didn't. Somewhat because I thought it was
obvious (an additional function call on every row). Still, as I've
mentioned in my initial post, I'm going to revisit the case in the
couple of days and gather more evidence.

Having said that, I'm really interested in any comments on the way I've
"imagined" addressing RLS years ago (and described it in the post), when
I've looked for a solution and settled for the rule system. The question
about partition/check/role approach irrespective of where they come from.

Pls address the following reasoning:
1. POLICY calls a function on every row to check it's visibility to the
client (for 1mln rows, 1mln checks).
2. "alternative" does just one check on all the rows contained in a
particular partition (for 100 tenets 100 checks)

No matter how hard one optimises the POLICY function, it will always loose.

Then again, I'll be back with some "ANALYSE" in a couple of days.

-R



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: sql3types.h does not include "BigInt"
Next
From: Marc
Date:
Subject: how to troubleshoot: FATAL: canceling authentication due to timeout