为什么散列连接在PostgreSQL9.1中比较慢？

Question

我用PostgreSQL9.1将DB从Postgresql 8.4转移到新服务器。DB的大小是9.9GB，数据目录位于ssd 60 DB磁盘上。服务器有16 16内存和16个处理器核。

但是今天的平均负荷已经增长到70。

我发现查询在计划中使用散列连接，我的一个查询在16m中执行，但当我设置enable_hashjoin = off时，设置enable_mergejoin = off时，它变成了使用嵌套循环，并在12 my中执行。

为什么postgresql不使用最优查询计划？

解释我粘贴到http://explain.depesz.com/s/764 (使用enable_hashjoin = on) http://explain.depesz.com/s/weY (使用嵌套循环)的分析结果

Answer 1

因为它认为这将是一个更快的计划。

c和u表的连接非常复杂。它是如此复杂，以至于Postgres无法预测这个联接将返回多少行-当它实际上只返回4行时，它认为它将返回超过160万行。

尽量简化您的查询--不要在联接中使用coalesce或case，也许可以将c.user_id=?和c.expert_id=?分为2个查询，并将其union all。如果在rows x列中explain.depesz.com上有任何红细胞，那么查询的糟糕和良好的性能将是非常随机的。