8

描述:这是性能问题的示例演示。

我们首先创建了两个表,启用了行级安全性并创建了策略。

表定义:

create table sample_schema.sample_table1(ID numeric(38) PRIMARY KEY NOT NULL,
                 tenant_id VARCHAR(255) NOT NULL,
                 Description VARCHAR(255)
        );

create table sample_schema.sample_table2(ID2 numeric(38) PRIMARY KEY NOT NULL,
                 tenant_id VARCHAR(255) NOT NULL,
                 table1_id numeric (38),
                 Description2 VARCHAR(255)
        );    

索引创建:

CREATE UNIQUE INDEX sample_table1_idx1 ON sample_schema.sample_table1(tenant_id,id);            

启用行级安全性:

ALTER TABLE sample_schema.sample_table1 ENABLE ROW LEVEL SECURITY;   

创建角色:

CREATE ROLE tenant_grp_role_p_id;    

创建策略:我想要一个策略来选择其中tenant_id 列值具有与已登录用户相同的角色的数据。

CREATE POLICY Tenant_Roles ON  sample_schema.sample_table1 TO tenant_grp_role_p_id USING ((tenant_id) IN ( SELECT rolname FROM pg_roles WHERE    pg_has_role( current_user, oid, 'member')));

创建样本数据:

insert into sample_schema.sample_table1 values (1,'user1_tenant1',1,'Table1 Data');
insert into sample_schema.sample_table2 values (2,'user1_tenant1',1,'Table2 Data');

问题:下面的查询没有使用 primary_key 索引。

SELECT * FROM sample_schema.sample_table1 ST1,  sample_schema.sample_table2 T2 WHERE ST1.id = ST2.table1_id  AND ST1.id = 1;    

问题:如果我禁用 RLS 则使用主键索引。为什么启用 RLS 时不使用主键索引扫描?

注意: A.
如果我禁用行级安全性并运行上述查询,它将使用索引。
B.下面是禁用低级安全性时的解释计划输出。

Nested Loop  (cost=0.29..19.19 rows=1 width=1129)  ->  Index Scan using sample_table1_pkey on sample_table1 st1  (cost=0.29..8.30 rows=1 width=37)
    Index Cond: (id = '1'::numeric)  ->  Seq Scan on sample_table2 st2  (cost=0.00..10.88 rows=1 width=1092)        Filter: (table1_id = '1'::numeric);    

C.如果我启用低级安全性并运行它不使用索引的查询。
以下是启用低级别安全性时的解释计划输出。

 Nested Loop  (cost=1.03..946.65 rows=79 width=1129) ->  Seq Scan on sample_table2 st2  (cost=0.00..10.88 rows=1 width=1092)  Filter: (table1_id = '1'::numeric)  ->  Subquery Scan on st1  (cost=1.03..934.98 rows=79 width=37)
    Filter: (st1.id = '1'::numeric)        ->  Hash Join  (cost=1.03..738.11 rows=15750 width=37)              Hash Cond: ((st1_1.tenant_id)::name = pg_authid.rolname)              ->  Seq Scan on sample_table1 st1_1  (cost=0.00..578.00 rows=31500 width=37)              ->  Hash  (cost=1.01..1.01 rows=1 width=68)                    ->  Seq Scan on pg_authid  (cost=0.00..1.01 rows=1 width=68)                          Filter: pg_has_role("current_user"(), oid, 'member'::text);   

请帮我解决这个问题..

4

1 回答 1

13

有关详细信息,请参阅pgsql-general 邮件列表上的此消息线程。

我最近将 RLS 应用于我的 9.5 数据库中的几个大型(数百万行)表,并注意到针对单个大型 RLS 保护表的查询执行良好,但连接多个大型 RLS 保护表的查询执行得很差。解释计划显示优化器正在扫描整个表以在执行主键连接之前执行 RLS 策略,这会将查询结果减少到每个表的单行。显然,如果它在策略检查之前执行连接,性能会更好。

据我所知,RLS 实现力求在用户提供谓词检查之前执行策略检查,以避免泄露受保护的数据。

和回应:

带有 RLS 的连接案例目前没有得到很好的优化。正在努力改进这一点 - 请参阅 https://www.postgresql.org/message-id/flat/8185.1477432701%40sss.pgh.pa.us - 但它不会在 v10 之前投入生产。

和:

您可以使用由同一用户拥有的安全屏障视图,该用户拥有下面的表,这将绕过表本身的 RLS,因此您需要在安全屏障视图中实现适当的 quals。

所以你可以等待 PG10,或者尝试使用安全屏障视图。那篇博文还解释了为什么 Postgres 不尝试结合(和优化)安全条件和用户指定的条件:自定义函数可用于泄漏原本对用户隐藏的值。

要创建这样的视图,只需添加with (security_barrier)到定义中:

rhaas=# create or replace view unclassified_emp with (security_barrier) as
        select * from emp where organization <> 'CIA';
CREATE VIEW

在这篇详细的博客文章中也有更多信息。

于 2017-07-20T11:42:40.077 回答