Postgresql join_collapse_limit 和查询计划的时间

Question

我刚刚发现join_collapse_limit 一直在阻止 PostgreSQL 规划器找到更好的连接顺序。在我的例子中，将限制增加到 10（从默认值 8）允许规划器将搜索时间从大约 30 秒缩短到大约 1 毫秒，这更容易接受。

文档建议将此“设置得太高”可能会导致规划时间过长，但甚至没有提供关于规划步骤对于各种值可能需要多长时间的“经验法则”。我知道一般问题在时间上是指数级的，但我找不到确定实际计划时间的方法，除非它只是运行ANALYZE SELECT ... 所需的时间。如果是这样的话，我相信现代计算机的默认值 8 是相当低的，因为我发现 8 和 10 之间的规划速度没有差异。

问题：

1) 如何衡量计划时间？

2) 大约，join_collapse_limit 可以达到多高，并且仍然预计计划花费不到几百毫秒？

Answer 1

1) 如何衡量计划时间？

新的 PostgreSQL 9.4 版本（在撰写本文时尚未发布）将在 EXPLAIN 和 EXPLAIN ANALYZE 中添加计划时间，因此您将能够使用它们。

对于旧版本，您的假设是正确的，确定计划时间的更好方法是执行简单的EXPLAIN（不是ANALYZE）并检查它所花费的时间，在psql 中，您可以通过启用\timing（我通常在 ~/.psqlrc 这样做）。

2) 大约，join_collapse_limit 可以达到多高并且仍然期望 计划花费不到几百毫秒？

The PostgreSQL hackers team already discussed about raising it to bigger values。但看起来他们不能保证它对所有情况都有好处。

问题在于，为N 表找到最佳连接顺序的计划采用O(N!)（阶乘）方法。因此，加薪的数字非常高，您可以通过以下查询简单地看到：

$ SELECT i, (i)! AS num_comparisons FROM generate_series(8, 20) i;
 i  |   num_comparisons   
----+---------------------
  8 |               40320
  9 |              362880
 10 |             3628800
 11 |            39916800
 12 |           479001600
 13 |          6227020800
 14 |         87178291200
 15 |       1307674368000
 16 |      20922789888000
 17 |     355687428096000
 18 |    6402373705728000
 19 |  121645100408832000
 20 | 2432902008176640000
(13 rows)

如您所见，在默认值 8 下，我们最多进行大约 40K 比较，您建议的 10 使其进入 3M，这对于现代计算机来说仍然不是很多，但是下一个值开始变得太大，它只是增长太快，20 简直太疯狂了（21！甚至不适合 64 位整数）。

当然，有时您可以将其设置为更大的值，例如 16，这可以（理论上）进行大约 20 万亿次比较，并且仍然有很好的规划时间，这是因为 PostgreSQL 在规划时会削减一些路径并且不要'不需要总是检查所有订单，但假设总是如此并将如此高的值设为默认值，这对我来说似乎不是一个好方法。将来可能会出现一些意外查询，使其检查所有订单，然后您只有一个查询会导致服务器停机。

根据我的经验，我假设 10 作为任何安装在好的服务器上的默认值，其中一些我什至使用 12。我建议您将其设置为 10，如果您愿意，有时也可以尝试设置它更高（我不会超过 12）并继续（密切）监视以查看它的行为。