Postgresql 如何调整查询计划器'；这是不准确的行估计

我正在使用Postgresql 9.5.4

我有一个查询，在运行analyze之后，从几秒钟到30分钟。我读过关于不同成本参数的书，并对它们进行了处理，我将默认的静态目标增加到10000（并再次分析），我清空了，我重新编制了索引，等等。 查看了查询的解释输出后，我发现了问题所在——查询计划器估计一个操作只有一行，而实际上有5000+行（如解释分析所示）。结果，查询选择执行嵌套循环（而不是散列联接）；考虑到它认为只有一行，我认为调整成本参数不会解决任何问题（如果它认为成本接近0，那么改变我们乘以的值不会改变它的选择）

在我的例子中，我发现删除一个相关的索引会迫使Postgresql使用一个哈希连接来修复性能，但是这个“解决方案”非常特定于这个查询和表（我不理解）

所以我的问题是：一般来说，当查询计划器严重低估（或高估）一个操作的行数时，我如何纠正它以便它能够找到更好的计划

最重要的是，如果您的查询经常受到计划者低估行的影响，那么有没有不同的编写方法来避免这种情况

---

（关于规划师为何会对行进行如此糟糕的估计，其他人的一个参考是在“相关列”下）

我认为这个问题太笼统了，不能给出一个好的答案。也许，但我并不期待更多的是“最佳实践”类型的答案。

它认为只有一行

text/varchar列？1）有多少个范围表条目？2） 数据模型是否符合BCNF？3） 具有两个或多个候选键的表？4） 搜索/连接非键属性？0）如果知道对所需表子集的子查询只生成两个结果元组，则可以将这些结果元组压缩到CTE中，在大多数情况下强制进行（可能两个…）哈希连接。1） 嗯,；（0）在这里也有帮助2）因此仍然可能存在可传递的依赖项。。3） FKs的基数？4） 疑犯。这些是稀疏统计的吗？（还有：编码？）顺便说一句：统计数据中最常见的值存在一个已知问题（可以在第9.6页中修复），您的问题可能就是这一问题的一个表现。