使用 SSD 时我应该在 PostgreSQL 上禁用位图扫描吗？答案

【问题标题】：Should I disable bitmapscan on PostgreSQL when using SSD?使用 SSD 时我应该在 PostgreSQL 上禁用位图扫描吗？
【发布时间】：2018-07-30 06:13:52
【问题描述】：

我正在阅读 https://use-the-index-luke.com/sql/where-clause/the-equals-operator/concatenated-keys 当我遇到这些行时：

在这种情况下，PostgreSQL 数据库使用两个操作：位图索引扫描，然后是位图堆扫描。它们大致对应Oracle的INDEX RANGE SCAN和TABLE ACCESS BY INDEX ROWID，有一个重要区别：它首先从索引中获取所有结果（Bitmap Index Scan），然后根据行在堆表中的物理存储位置对行进行排序然后从表中获取所有行（位图堆扫描）。这种方法减少了表上随机访问IO的数量。

我突然想到，当我们在 SSD 上使用 Postgres 时，这没有任何意义。分类存储位置的计算可能是一种浪费。因为 SSD 是仅限随机访问的设备（如果我没记错的话。）

我也做了一些测试，打开/关闭enable_bitmapscan

set enable_bitmapscan to on;
explain analyse select count(distinct myid) from experiment.mytable where name='my_name';
----
QUERY PLAN
Aggregate  (cost=63196.06..63196.07 rows=1 width=8) (actual time=668.845..668.846 rows=1 loops=1)
  ->  Bitmap Heap Scan on mytable  (cost=696.41..63110.95 rows=34045 width=82) (actual time=54.967..216.382 rows=178705 loops=1)
        Recheck Cond: (name = 'my_name'::text)
        Heap Blocks: exact=164942
        ->  Bitmap Index Scan on mytable_name_visittime_idx  (cost=0.00..687.89 rows=34045 width=0) (actual time=28.365..28.365 rows=178705 loops=1)
              Index Cond: (name = 'my_name'::text)
Planning time: 1.411 ms
Execution time: 669.576 ms



set enable_bitmapscan to off;
explain analyse select count(distinct myid) from experiment.mytable where name='my_name';
----
QUERY PLAN
Aggregate  (cost=68369.46..68369.47 rows=1 width=8) (actual time=585.496..585.497 rows=1 loops=1)
  ->  Index Scan using mytable_name_visittime_idx on mytable  (cost=0.56..68284.34 rows=34045 width=82) (actual time=0.019..126.553 rows=178705 loops=1)
        Index Cond: (name = 'my_name'::text)
Planning time: 0.062 ms
Execution time: 585.542 ms

确实有明显改善当 enable_bitmapscan 规划器使用 BitmapHeapScan + BitmapIndexScan。当禁用它时，规划器只选择 IndexScan。

【问题讨论】：

确实 SSD 的寻道时间非常短 - 因此禁用为旋转磁盘设计的优化是值得的。

标签： sql postgresql

【解决方案1】：

您还可以调整配置，让 PostgreSQL 决定随机 IO 成本是否会高于顺序成本。

将postgresql.conf中的this setting - random_page_cost改为1.0，相当于seq_page_cost。

这将告诉 PostgreSQL 随机 IO 的成本等于顺序 IO 的成本。

【讨论】：