Postgres с безопасностью на уровне строк не оптимизирует запросы/использует одноразовые фильтры

Кажется, что postgres с включенной безопасностью на уровне строк в таблице не может должным образом оптимизировать запросы. Следующий пример sql демонстрирует проблему:

begin transaction;
    -- create demo table
    create table entries (id int primary key);

    -- setup rls
    alter table entries enable row level security;
    create policy entries_policy on entries for all using (
        current_setting('app.can_read_entries')::boolean = true
    );

    -- setup a role which cannot bypass rls
    create role authenticated;
    grant usage on schema public to authenticated;
    grant select on all tables in schema public to authenticated;

    -- configure setting (just as an example for a query condition)
    set local app.can_read_entries = true;
rollback;

Если не используется RLS:

explain
select * from entries
where (
    -- Simulate RLS query as superuser which bypasses RLS by adding the RLS condition manually
    current_setting('app.can_read_entries')::boolean = true
);

-- Result  (cost=0.01..35.51 rows=2550 width=4)
--   One-Time Filter: (current_setting('app.can_read_entries'::text))::boolean
--   ->  Seq Scan on entries  (cost=0.01..35.51 rows=2550 width=4)

тогда как с безопасностью на уровне строк это будет

-- switch to 'authenticated' role to use rls in queries
set local role 'authenticated';

-- run the query with rls inlining its conditions
explain
select * from entries;

-- Seq Scan on entries  (cost=0.00..54.63 rows=1275 width=4)
--   Filter: (current_setting('app.can_read_entries'::text))::boolean

В первом запросе без rls оптимизатор правильно распознает, что условие является статическим для запроса, и извлекает его как проверку однократного фильтра. Но второй запрос, в котором условие предоставляется rls, не оптимизируется полностью, и postgres будет оценивать условие для каждой строки, даже если оно является постоянным для всего запроса.

В этом примере данных немного, а запрос простой, однако он довольно легко демонстрирует проблему, и такое же поведение можно наблюдать в таблицах с большим количеством данных, индексов и т. д. Более подробный пример описан здесь: https: //pastebin.com/iQu6L5Sj

Я уже читал об атрибуте герметичности функций и пробовал установить атрибут герметичности current_setting и даже пошел и попробовал update pg_proc set proleakproof = true;.

Однако, что бы я ни пытался, postgres не будет должным образом оптимизировать запрос с безопасностью на уровне строк.

Обновлено: Еще один пример, в котором не используется такая функция, как current_setting:

-- additionally create a users table
create table users (id int primary key);
-- and then use this policy
create policy entries_policy on entries for all using (
    exists (select 1 from users where id = 1)
    -- current_setting('app.can_read_entries')::boolean = true
);

Без RLS он будет работать как

Result  (cost=8.17..43.67 rows=2550 width=4)
  One-Time Filter: $0
  InitPlan 1 (returns $0)
    ->  Index Only Scan using users_pkey on users  (cost=0.15..8.17 rows=1 width=0)
          Index Cond: (id = 1)
  ->  Seq Scan on entries  (cost=8.17..43.67 rows=2550 width=4)

а с помощью RLS он будет напрямую выполнять сканирование последовательности вместо использования раннего возврата:

Seq Scan on entries  (cost=8.17..43.67 rows=1275 width=4)
  Filter: $0
  InitPlan 1 (returns $0)
    ->  Index Only Scan using users_pkey on users  (cost=0.15..8.17 rows=1 width=0)
          Index Cond: (id = 1)