我正在使用Postgresql 9.5.4。
我有一个问题，在运行分析后，需要几秒钟才能完成30多分钟。我已经阅读了不同的成本参数并使用它们，我已经将default_statics_target增加到10000（并再次分析），我已经吸尘，我已经重新编制索引等。 查看了查询的EXPLAIN输出后，我发现了问题 - 查询计划程序估计只有一行操作，而实际上有5000行（如EXPLAIN ANALYZE所示）。因此，查询选择执行嵌套循环（而不是散列连接）;并且鉴于它只相信只有一行，我认为对成本参数的调整不会解决任何问题（如果它认为成本接近0，那么改变它们乘以它不会改变它的选择）
在我的情况下，我发现删除相关索引迫使Postgresql使用修复性能的散列连接，但这个“解决方案”非常特定于此查询和表（我不明白）。
所以我的问题是：在 general 中，当查询规划器大大低估了操作的行数（或过高估计）时，如何更正它以便找到更好的计划？
最重要的是，如果您的查询经常遭受计划者低估他们的行的影响，是否有提示以不同的方式编写它们以避免这种情况？
（关于规划师为什么如此严重地估计行数的其他人的一个参考是“依赖列”下的here