And*_*cus 6 postgresql postgresql-12 jit
tl; dr：处理由 jit 引起的性能下降的最佳方法是什么？
背景：
最近我从 postgres 11 迁移到 12 并注意到，一些查询/程序运行得相当慢。我做了一些研究并测试了不同的配置 - 结果表明 jit 开销超过了它的收益。我看到两种可能的解决方案：
通过运行set jit = off;一次永久禁用所有查询的 jit 。这有帮助，但感觉不自然。（也许是因为更改了默认配置，我没有做太多，因为没有这样的需要。默认值是理智的，需要更改的可能性很小。）这也意味着在运行长查询时放弃可能的性能提升.
在程序开始时禁用 jit 并在结束时启用它。我反对更改配置对并行运行的查询的影响。当然，这会损害日志查询的性能，这些查询会同时运行，但这可能会导致其他可能难以检测的错误。此外，这似乎比第一个解决方案更不正确 - 作为程序的一部分更改配置。
处理这个问题的最好方法是微调配置，这样 jit 就不会被完全丢弃，而且配置也不会在运行时改变。不幸的是，我发现几乎没有任何资源如何，这将是可能的（只有像参数jit_above_cost中的文件，似乎是帮助不大）。
问题：解决此问题的最佳方法是什么？除了运行和测量之外，是否有关于何时禁用 jit 的任何标准？是否可以微调行为（例如，针对特定查询禁用 jit）？
jja*_*nes 10
在我看来，在 v12 中将 jit 的默认值更改为“on”是一个错误，因此基于这一观点，再次关闭它对我来说似乎很自然。如果我当时更加关注的话，我会反对这种改变（当然，这并不意味着我会获胜）。这一变化似乎带来的伤害至少和它带来的帮助一样多。期待该功能的人们肯定会去更改默认设置。
默认值是合理的，需要更改的可能性很小
我认为您对一般默认设置过于尊重。它们基本上是针对最小可信机器尺寸而设置的。即使通常选择得好的设置也可能不适合您。
这也意味着在运行长查询时放弃可能的性能提升。
您有此类查询的示例吗？一般来说，当查询运行时间足够长，以至于 jit 有意义时，它也会开始接触足够多的数据，不再受 CPU 限制，因此是否使用 jit 相对不重要（或者它缺少索引，修复比 jit 重要得多）。当然，这并不普遍正确，如果您有一个示例，则可以使用它来定位 jit_above_cost 的设置。（jit_above* 的一个问题是它们基于总成本估算，而总成本估算通常以 IO 成本估算为主。但是根据估算的 IO 成本选择使用或不使用 JIT 是没有意义的。但基础设施却是这样的。 t 可以将这些类型的成本估算分开。）