PostgreSQL 函数内部的智能逻辑查询性能

Question

考虑以下 sql 查询：

SELECT a,b,c
FROM t
WHERE (id1 = :p_id1 OR :p_id1 IS NULL) AND (id2 = :p_id2 OR :p_id2 IS NULL)

Markus Winand 在他的“SQL Performance explained”一书中将这种方法称为所有性能最差的反模式之一，并解释了原因（数据库必须为最坏的情况准备计划当所有过滤器都被禁用时）。

但后来他也写道，对于 PostgreSQL，这个问题只有在重新使用语句 (PreparedStatement) 句柄时才会出现。

现在还假设上面的查询被包装到函数中，例如：

CREATE FUNCTION func(IN p_id1 BIGINT,IN p_id2 BIGINT)
...
 $BODY$
  BEGIN
     ...
  END;
 $BODY$

到目前为止，我对几点有误解：

1. 在函数包装的情况下还会出现这个问题吗？ （我试图查看函数调用的执行计划，但即使使用SET auto_explain.log_nested_statements = ON，Postgres 也不会向我显示内部函数调用的详细信息）。

2. 假设我正在处理遗留项目，不能更改函数本身，只能更改 java 执行代码。在这里避免准备好的语句并每次使用动态查询会更好吗？ （假设执行时间很长，最多几秒钟）。说这个，大概是丑的做法：

---

getSession().doWork(connection -> {
    ResultSet rs = connection.createStatement().executeQuery("select * from func("+id1+","+id2+")");
    ...
})

Answer 1

1。 视情况而定。

当不使用准备好的语句时，PostgreSQL 每次都使用参数值重新计划一次查询。它被称为自定义计划。

使用准备好的语句（你是对的，PL/pgSQL 函数确实使用准备好的语句）它更复杂。 PostgreSQL 准备语句（解析其文本并存储解析树），但每次执行时都会重新规划它。自定义计划至少生成 5 次。之后，如果成本低于迄今为止生成的自定义计划的平均成本，则计划者会考虑使用 通用计划（即参数值独立）。

请注意，计划的成本是对计划者的估计，而不是实际的 I/O 操作或 CPU 周期。

所以，问题可能会发生，但你需要一些坏运气。

2。 您建议的方法不起作用，因为它不会改变函数的行为。

一般来说，PostgreSQL 不使用参数并不是那么难看（就像 Oracle 一样），因为 PostgreSQL 没有用于计划的共享缓存。准备好的计划存储在每个后端的内存中，因此重新计划不会影响其他会话。

但据我所知，目前没有办法强制规划器使用自定义计划（除了在 5 次执行后重新连接......）。