PostgreSQL 9.4中没有针对动态SQL的执行计划缓存？

Question

这只是一个潜在的问题，在工作中，我们正在考虑从SQL Server迁移到PostgreSQL，请告诉我，我对PostgreSQL 9.4文档的理解不正确：“没有计划缓存通过EXECUTE执行的命令”。

我们有一个关键的SP来构建动态查询并执行它，最初我没有正确地构建动态SQL（未对动态查询进行参数化），因此，每次命中此SP时，它花费约1500ms进行重新编译动态SQL（正在建立的查询非常庞大），执行该查询大约需要80毫秒（查询虽然很大，但并不昂贵）。

重新编写代码并将其参数化之后，执行计划变得非常稳定，现在SP通常仅需要80毫秒，因此通过这种方式，一旦查询被参数化，我就摆脱了重新编译性能的问题（当然当服务器重新启动时，执行计划缓存需要进行一些预热，但现在每个客户端仅执行一次慢查询（不同表中每个客户端的不同数据统计信息）

请告诉我，我对PostgreSQL 9.4文档的理解不正确，或者实际上存在一种缓存动态SQL执行计划的方法，因为回到〜1500ms的执行时间是不可接受的，并且使用静态SQL需要对开发人员进行大量更改，这绝对不是一个选择...

Answer 1

每个文档：

同样， 没有计划缓存通过EXECUTE命令。 而是总是在每次运行语句时计划命令。 因此，可以在函数中动态创建命令字符串，以对不同的表和列执行操作。

这是一个合理的功能 。 动态查询的本质是它在调用之间改变其结构。

如果要重复调用同一查询（可以选择使用不同的参数），请使用准备好的语句 ：

• 拆分给定的字符串并准备大小写语句

或在plpgsql函数中使用普通的（非动态）SQL代码，这些代码也像预处理语句一样对待。

在您的情况下 ，最好动态地进行PREPARE查询。 我们在这里有一个非常相似的案例：

• 使用功能的文本输出作为新查询

另外，查询花费1.4秒进行计划而执行仅花费0.1秒是非常罕见的。 可能值得研究。 可能有优化的方法。 像join_collapse_limit一样：

• 示例查询以显示PostgreSQL中的基数估计错误
• 答：由于行估计非常不准确，全文搜索速度很慢

有关：

• PostgreSQL存储过程性能
• 准备好的语句如何编译？