将SQL函数标记为防泄漏有任何性能优势吗？
PostgreSQL有一个属性LEAKRPOOF你可以用来声明一个函数，
函数没有副作用的
LEAKPROOFindicates。它除了通过其返回值外，不显示有关其参数的任何信息。例如，一个函数如果为某些参数值抛出错误消息，而不为其他参数值抛出错误消息，或者在任何错误消息中包含参数值，则不具有防泄漏性。<#>This会影响系统对使用security_barrieroption或启用行级安全性的表创建的视图执行查询的方式。系统将在用户提供的包含无泄漏功能的查询本身提供的条件之前，强制执行来自安全策略和安全屏障视图的条件，以防止无意中暴露数据。标记为防泄漏的函数和操作符被假定是可信任的，并且可以在安全策略和安全屏障视图的条件下执行。
The 医生接着说，
The查询规划器在处理没有副作用的函数时具有更大的灵活性。这些函数称为
LEAKPROOF**，包括许多简单的常用运算符，例如许多相等运算符。**查询规划器可以安全地允许在查询执行过程中的任何点计算这些函数，因为在用户不可见的行上调用这些函数不会泄露任何关于未见行的信息。此外，不接受参数或没有从安全屏障视图传递任何参数的函数不必标记为LEAKPROOF才能向下推，因为它们从不接收视图中的数据。相反，根据作为参数接收到的值可能引发错误(例如，在溢出或除以零时抛出错误的函数)并不是防泄漏的，如果应用在安全视图的行筛选器之前，则可以提供有关未见行的重要信息。
是以下LEAKRPOOF函数
CREATE FUNCTION foo_leakproof(bar int)
RETURNS int AS $
SELECT bar;
$
IMMUTABLE LEAKPROOF
LANGUAGE sql;是否有不同的计划或运行时配置文件与缺乏替代的LEAKPROOF不同，
CREATE FUNCTION foo_leaky(bar int)
RETURNS int AS $
SELECT bar;
$
IMMUTABLE
LANGUAGE sql;回答 1
Database Administration用户
发布于 2018-06-22 17:56:49
似乎在最简单的情况下，你和你的两个性能概要没有什么区别，
CREATE TABLE t1 AS
SELECT x::int FROM generate_series(1,1e6) AS gs(x);
CREATE VIEW v1 AS TABLE t1;
CREATE VIEW v2 WITH (security_barrier)
AS TABLE t1;
-- BASE TABLE
EXPLAIN ANALYZE SELECT foo_leaky(x) FROM t1;
EXPLAIN ANALYZE SELECT foo_leaky(x) FROM t1;
EXPLAIN ANALYZE SELECT foo_leaky(x) FROM t1;
EXPLAIN ANALYZE SELECT foo_leakproof(x) FROM t1;
EXPLAIN ANALYZE SELECT foo_leakproof(x) FROM t1;
EXPLAIN ANALYZE SELECT foo_leakproof(x) FROM t1;
-- VIEW
EXPLAIN ANALYZE SELECT foo_leaky(x) FROM v1;
EXPLAIN ANALYZE SELECT foo_leaky(x) FROM v1;
EXPLAIN ANALYZE SELECT foo_leaky(x) FROM v1;
EXPLAIN ANALYZE SELECT foo_leakproof(x) FROM v1;
EXPLAIN ANALYZE SELECT foo_leakproof(x) FROM v1;
EXPLAIN ANALYZE SELECT foo_leakproof(x) FROM v1;
-- VIEW with SECURITY_BARRIER
EXPLAIN ANALYZE SELECT foo_leaky(x) FROM v2;
EXPLAIN ANALYZE SELECT foo_leaky(x) FROM v2;
EXPLAIN ANALYZE SELECT foo_leaky(x) FROM v2;
EXPLAIN ANALYZE SELECT foo_leakproof(x) FROM v2;
EXPLAIN ANALYZE SELECT foo_leakproof(x) FROM v2;
EXPLAIN ANALYZE SELECT foo_leakproof(x) FROM v2;这些都是100-110毫秒。No性能的差异。
但是，更改要使用的函数
CREATE FUNCTION foo_leakproof(bar int)
RETURNS int AS $
SELECT bar+1;
$
IMMUTABLE LEAKPROOF
LANGUAGE sql;
CREATE FUNCTION foo_leaky(bar int)
RETURNS int AS $
SELECT bar+1;
$
IMMUTABLE
LANGUAGE sql;将使所有调用都变慢，但是在带有和不带v2的版本上，对security_barrier(我们的视图中有一个LEAKPROOF )的调用会大大地慢(慢2x)。这也与文件开始security_barrier达成一致，
使用security_barrier创建的视图可能比没有此选项的视图执行得糟糕得多。一般来说，没有办法避免这种情况:如果最快的计划可能危及安全，就必须予以拒绝。因此，默认情况下不启用此选项。
;tldr LEAKPROOF似乎永远不会使查询变慢。然而，在我的测试中，这也不能让它们更快。也许它提供了使用security_barrier对视图进行更大优化的能力，但我还没有创建这个环境。security_barrier在很大程度上减慢了视图的速度，并且应该只在需要时使用。
使用PostgreSQL 10.4完成的基准测试。
https://dba.stackexchange.com/questions/210390
复制相似问题
腾讯云开发者
