Re: Fwd: row level security (RLS)

Поиск
Список
Период
Сортировка
От Rafal Pietrak
Тема Re: Fwd: row level security (RLS)
Дата
Msg-id 52abbd1c-6d4f-6de0-1456-43ad81bcbfad@ztk-rp.eu
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: sql3types.h does not include "BigInt"
Следующее
От: Marc
Дата:
Сообщение: how to troubleshoot: FATAL: canceling authentication due to timeout