相关疑难解决方法(0)

Postgres 函数声明为波动性分类VOLATILE，STABLE或IMMUTABLE。众所周知，该项目对内置函数的这些标签非常严格。并且有充分的理由。突出的例子：表达式索引只允许IMMUTABLE函数并且那些必须是真正不可变的以避免错误的结果。

用户定义的函数仍然可以按照所有者的选择自由声明。手册建议：

为了获得最佳优化结果，您应该使用对它们有效的最严格的波动率类别来标记您的函数。

...并添加了大量可能因波动率标签不正确而出错的事情列表。

尽管如此，在某些情况下，伪造不变性是有道理的。大多数情况下，当您知道该函数实际上在您的范围内是不可变的。例子：

• PostgreSQL 是否支持“不区分重音”的排序规则？

除了对数据完整性的所有可能影响之外，对性能的影响是什么？人们可能认为声明一个函数IMMUTABLE只会对性能有益。是这样吗？

声明函数波动性会IMMUTABLE 损害性能吗？

让我们假设当前的 Postgres 10 来缩小范围，但所有最近的版本都很有趣。

执行 SQL 查询的普通 SQL 函数之间是否有区别：

create function get_sports() returns setof sport as
$body$
    select * from sport;
$body$
language sql stable;

和 PLPGSQL 函数返回相同的 SQL 查询：

create function get_sports() returns setof sport as
$body$
begin
    return query select * from sport;
end
$body$
language plpgsql stable;

关于性能？在什么情况下应该使用哪个版本？

如果我们传递参数，那会改变什么吗？如：

create function get_sports(status int) returns setof sport as
$body$
    select * from sport where status = $1;
$body$
language sql stable;

create function get_sports(status int) returns setof sport as
$body$
begin
    return …

Postgres 12 的手册说：

以下操作始终受到并行限制。

• 扫描公共表表达式 (CTE)。
• 临时表的扫描。
• ...

在同一手册页上进一步向下：

[...] 同样，PARALLEL RESTRICTED如果函数访问临时表、客户端连接状态、游标、准备好的语句或系统无法跨工作器同步的其他后端本地状态，则必须标记它们。例如，由于最后一个原因setseed而random受到并行限制。

没有提到 CTE。现在我不确定我是否可以PARALLEL SAFE用于包含 CTE 的函数。对我来说只有PARALLEL RESTRICTED.

上下文：我必须确定现有用户定义函数的最佳标签。该设置是自 Postgres 9.6 以来的新设置，并且可以对性能产生巨大影响，因为涉及PARALLEL SAFE并行工作人员不会执行的功能的操作，PARALLEL RESTRICTED只能由领导者执行。（并PARALLEL USAFE完全禁用并行性。）

我在 pgsql-general 上发布了一个相关的问题。

我正在对我公司的一些 SQL 进行一些性能基准测试，将 PG10 与 PG12 进行比较。我们在代码中使用了很多CTE，而 PG12 并没有对 CTE 进行原生优化，因此 PG10 和 PG12 之间的性能是相同的。

我的下一个实验是将NOT MATERIALIZED指令添加到 CTE，结果令人震惊：它大大缩短了查询时间（在某些情况下将它们减半）。

我在这里读到这MATERIALIZED是 PG12 之前的默认功能。该功能会将 CTE 的所有内容写入一个临时位置。

所以我的问题主要是NOT MATERIALIZED：

1. 与 相比，该NOT MATERIALIZED功能对幕后的数据MATERIALIZED有何作用？
2. NOT MATERIALIZED在重构我们的代码库之前，我应该注意哪些副作用？