Postgresql join_collapse_limit 和查询规划的时间

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

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

问题：

1）如何衡量计划时间？

2）大约可以多高join_collapse_limit是否并且仍然期望计划花费的时间少于几百毫秒？

1）如何衡量计划时间？

新的 PostgreSQL 9.4 版本（在撰写本文时尚未发布）将把规划时间添加到EXPLAIN and EXPLAIN ANALYZE，这样您就可以使用它们了。

对于旧版本，您的假设是正确的，确定计划时间的更好方法是执行一个简单的EXPLAIN (no ANALYZE）并检查所花费的时间，在psql你可以通过启用来做到这一点\timing（我通常在~/.psqlrc).

2) join_collapse_limit 大约可以达到多高并且仍然期望 计划花费少于几百毫秒的时间？

PostgreSQL 黑客团队已经讨论过将其提高到更大的值。但看起来他们不能保证这对所有情况都有好处。

问题在于，计划找到最佳的连接顺序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 在规划时切断了一些路径，并且不需要到always检查所有订单，但假设情况总是如此，并将如此高的值设置为默认值，对我来说似乎不是一个好方法。将来可能会出现一些意外的查询，导致它需要检查所有订单，然后您只有一个查询导致服务器停机。

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