Postgres 解释计划不同

Question

我有 2 个数据库在同一台服务器上运行。 两者都是具有相同结构但数据量不同的开发数据库。 在 Linux (Centos/Redhat) 上运行 Postgres 9.2

我在每个数据库上运行以下 SQL，但在性能上得到了非常不同的结果。

注意：每个 DB 中的 write_history 表结构相同，并且具有相同的索引/约束。

这里是 SQL：

 explain analyze SELECT * FROM write_history WHERE fk_device_rw_id =
 'd2c969b8-2609-11e3-80ca-0750cff1e96c'  AND fk_write_history_status_id
 = 5  ORDER BY update_time DESC LIMIT 1 ;

以及每个数据库的解释计划：

DB1 - PreProd

 Limit  (cost=57902.39..57902.39 rows=1 width=103) (actual
 time=0.056..0.056 rows=0 loops=1)'   ->  Sort 
 (cost=57902.39..57908.69 rows=2520 width=103) (actual
 time=0.053..0.053 rows=0 loops=1)'
         Sort Key: update_time'
         Sort Method: quicksort  Memory: 25kB'
         ->  Bitmap Heap Scan on write_history  (cost=554.04..57889.79 rows=2520 width=103) (actual time=0.033..0.033 rows=0 loops=1)'
               Recheck Cond: (fk_device_rw_id = 'd2c969b8-2609-11e3-80ca-0750cff1e96c'::uuid)'
               Filter: (fk_write_history_status_id = 5)'
               ->  Bitmap Index Scan on idx_write_history_fk_device_rw_id  (cost=0.00..553.41 rows=24034
 width=0) (actual time=0.028..0.028 rows=0 loops=1)'
                     Index Cond: (fk_device_rw_id = 'd2c969b8-2609-11e3-80ca-0750cff1e96c'::uuid)' Total runtime: 0.112 ms'

DB2 - 质量检查

 Limit  (cost=50865.41..50865.41 rows=1 width=108) (actual
 time=545.521..545.523 rows=1 loops=1)'   ->  Sort 
 (cost=50865.41..50916.62 rows=20484 width=108) (actual
 time=545.518..545.518 rows=1 loops=1)'
         Sort Key: update_time'
         Sort Method: top-N heapsort  Memory: 25kB'
         ->  Bitmap Heap Scan on write_history  (cost=1431.31..50762.99 rows=20484 width=108) (actual time=21.931..524.034 rows=22034
 loops=1)'
               Recheck Cond: (fk_device_rw_id = 'd2cd81a6-2609-11e3-b574-47328bfa4c38'::uuid)'
               Rows Removed by Index Recheck: 1401986'
               Filter: (fk_write_history_status_id = 5)'
               Rows Removed by Filter: 40161'
               ->  Bitmap Index Scan on idx_write_history_fk_device_rw_id  (cost=0.00..1426.19 rows=62074
 width=0) (actual time=19.167..19.167 rows=62195 loops=1)'
                     Index Cond: (fk_device_rw_id = 'd2cd81a6-2609-11e3-b574-47328bfa4c38'::uuid)' Total runtime: 545.588 ms'

有几个问题：

1. “排序方法：快速排序内存：25kB”和“排序方法：top-N 堆排序内存：25kB”有什么区别？

2. 总运行时间如此不同的原因可能是什么？

表格行数：

DB1：write_history 行数：5,863,565

DB2：write_history 行数：2,670,888

如果需要更多信息，请告诉我。 感谢您的帮助。

Answer 1

top-N 排序意味着它正在排序以支持 ORDER BY ... LIMIT N，并且一旦它可以表明元组不能在前 N 中，它将丢弃任何元组。切换的决定在排序过程中动态进行前 N 排序。由于该排序的输入元组为零，因此它从未决定切换到它。因此，报告方法的差异是结果，而不是原因；并且对本案无关紧要。

我认为你的关键是位图堆扫描：

(actual time=0.033..0.033 rows=0 loops=1)

(actual time=21.931..524.034 rows=22034 loops=1)

较小的数据库有很多 更多 行符合您的条件，因此还有很多工作要做。

还有，需要完成的复查工作量：

Rows Removed by Index Recheck: 1401986

建议您将 work_mem 设置为一个非常小的 work_mem 值，因此您的位图会溢出它。

Answer 2

1) 两种不同的排序算法。

http://en.wikipedia.org/wiki/Quicksort

http://en.wikipedia.org/wiki/Heapsort

2) 被排序的数据量会改变决定。

来自数据库理论的记忆；由于它扫描数据的顺序，QuickSort 在大量数据上的表现非常糟糕。如果排序需要缓存到磁盘，那就特别糟糕了。堆排序比快速排序有更好的最坏情况。查询计划者知道这一点，并将相应地更改计划。

被排序的行数增加了 8 倍。要非常小心地注意预期要选择的行数以及表中的行数。查询计划器使用数据的直方图来更好地了解将选择的内容，而不仅仅是表中的行数。在 DB1 中为 2.5K，在 DB2 中为 20K

您可以通过检查结果行集是否与估计值中的计数匹配来检查这些估计值是否正确。如果没有，请考虑执行ANALYZE