时间戳

首页 > 解决方案 > 解释分析 - 成本与实际时间的关系

postgresql - 解释分析 - 成本与实际时间的关系

问题描述

通常在改进我的查询时，我看到两者的改进是一致的，cost并且在查询前后都actual time运行时。explain analyze

但是，在一种情况下，之前的查询报告

"Hash Join  (cost=134.06..1333.57 rows=231 width=70) 
            (actual time=115.349..115.650 rows=231 loops=1)"
<cut...>
"Planning time: 4.060 ms"
"Execution time: 115.787 ms"

以及之后的报道

"Hash Join  (cost=4.63..1202.61 rows=77 width=70) 
            (actual time=0.249..0.481 rows=231 loops=1)"
<cut...>
"Planning time: 2.079 ms"
"Execution time: 0.556 ms"

如您所见，成本相似，但实际执行时间和实际执行时间大不相同，无论我运行测试的顺序如何。

使用 Postgres 8.4。

谁能澄清我对为什么成本没有改善的理解？

标签： postgresqlpostgresql-8.4

解决方案

问题中给出的详细信息中没有太多可用信息，但一些指针可能会帮助其他来这里搜索该主题的人。

  • 成本是基于在查询中涉及的表上运行分析时计算的表统计信息的数值估计。如果表格从未被分析过，那么计划和成本可能是次优的。查询计划受表统计信息的影响。
  • 实际时间是运行查询所用的实际时间。同样，这可能与成本不正确相关，具体取决于表统计信息的新鲜程度。该计划可能会根据当前表的统计信息来实现，但实际执行时可能会发现与表统计信息不同的真实数据条件，从而导致执行时间倾斜。

这里需要注意的是，表统计影响计划和成本估算，而计划和实际数据条件影响实际时间。因此，作为最佳实践，在进行查询优化之前，始终对表运行分析。

几点注意事项：

  • analyze <table>- 更新表的统计信息。
  • vacuum analyze <table>- 从表中删除更新记录的陈旧版本，然后更新表的统计信息。
  • explain <query>- 仅使用查询中涉及的表的统计信息生成查询计划。
  • explain (analyze) <query>- 使用查询中涉及的表的现有统计信息生成查询计划，并运行查询以收集实际运行时数据。由于查询实际上是运行的，如果查询是 DML 查询，那么如果不打算保留更改，则应注意将其包含在 begin 和 rollback 中。

推荐阅读