Question

我刚刚发现join_collapse_limit一直在阻止PostgreSQL规划器找到更好的连接顺序。在我的情况下，将限制增加到10（从默认值8开始）允许规划人员将搜索时间从大约30秒提高到大约1毫秒，这是更可接受的。

文档建议将此设置为太高＆＃34;可能会导致计划时间过长，但甚至不能提供经验法则。关于各种价值观的规划步骤可能有多长。我理解一般问题在时间上是指数级的，但我找不到确定实际计划时间的方法，除非它只是运行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在规划时削减了一些路径并且＃39;需要始终检查所有订单，但假设它总是如此，并将默认值设为如此高的值，对我来说不是一个好方法。将来可能会有一些意外的查询，它会检查所有订单，然后您只有一个查询可以关闭服务器。

根据我的经验，我认为10是优质服务器上任何安装的默认值，其中一些我甚至使用12.如果你愿意，我建议你把它设置为10，并且在某些时候，尝试设置它更高（我不会超过12）并继续监控（密切）以查看它的行为。

Postgresql join_collapse_limit和查询计划的时间

1 个答案: