![为什么 postgresql 9.1 中的哈希连接很慢?](https://linux22.com/image/610529/%E4%B8%BA%E4%BB%80%E4%B9%88%20postgresql%209.1%20%E4%B8%AD%E7%9A%84%E5%93%88%E5%B8%8C%E8%BF%9E%E6%8E%A5%E5%BE%88%E6%85%A2%EF%BC%9F.png)
我将数据库从 Postgresql 8.4 转移到了装有 Postgresql 9.1 的新服务器。数据库大小为 9.9GB,数据目录位于 60GB 的 SSD 磁盘上。服务器有 16GB RAM 和 16 个处理器核心。
但是今天平均负载已上升到 70。
我发现查询在计划中使用了哈希连接,并且我的一个查询在 16 分钟内执行完成,但是当我设置 enable_hashjoin = off 时,它在 5 分钟内执行完成,而当我设置 enable_mergejoin = off 时,它变为使用嵌套循环并在 12ms 内执行完成。
为什么postgresql不使用最佳查询计划?
解释分析我粘贴的结果http://explain.depesz.com/s/764(启用了 enable_hashjoin = 开启)http://explain.depesz.com/s/weY(带有嵌套循环)
答案1
因为它认为这将是一个更快的计划。
c
您有非常复杂的和表连接u
。它太复杂了,以至于 Postgres 无法预测此连接将返回多少行 — 它认为它将返回超过 1600000 行,但实际上它只返回 4 行。
尝试简化您的查询 — 不要在连接中使用coalesce
或,也许将和分为 2 个查询并将它们分开。如果 explain.depesz.com 上的列中有任何红色单元格,则查询的糟糕和良好性能将非常随机。case
c.user_id=?
c.expert_id=?
union all
rows x