嵌套循环中成本和行数估计之间的差异

Question

我有一段 PostgreSQL 解释计划的片段，我正在尝试理解：

 ->  Nested Loop  (cost=0.57..933455.16 rows=11 width=122) (actual time=3.710..497.990 rows=86102 loops=1)
       ->  CTE Scan on last_outputs  (cost=0.00..5.02 rows=251 width=172) (actual time=3.675..333.800 rows=1773 loops=1)
       ->  Index Scan using i_batch_company_outputs_file_md5 on batch_company_outputs bco2  (cost=0.57..3718.91 rows=1 width=65) (actual time=0.019..0.080 rows=49 loops=1773)
             Index Cond: ((file_md5)::text = (last_outputs.file_md5)::text)
             Filter: (((service_id)::text = 'sheetbuilder'::text) AND ((file_name)::text = 'output.txt'::text) AND ((last_outputs.company_id)::text = ((company_id)::text || ''::text)))
             Rows Removed by Filter: 9

根据我的理解：

• 索引扫描 i_batch_company_outputs_file_md5 估计成本较低，并且在实践中执行得非常快（正如我所期望的）
• 过滤器的作用很小（也是我所期望的）
• 循环实际上返回的行数比估计建议的多得多

尽管如此，仍然存在相对较高的成本估计（933455.16），这似乎无法由循环内的任何操作来解释。为什么？我还可以尝试其他方法来更好地了解该数字的来源吗？

Answer 1

我不会将 3718.91 称为索引扫描一次迭代的低成本估计。我不知道是什么导致了高成本估计，我假设 file_md5 不是索引 i_batch_company_outputs_file_md5 中的第一列（尽管名称表明它是。）

3718.91 * 251 = 933446.41，这确实清楚地解释了总成本估算。 （部分）计划存在差异，但您提出的问题与实际差异无关。