使用SSD时是否应在PostgreSQL上禁用位图扫描？

我在看报纸 当我遇到这些问题时：

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

我突然想到，当我们在SSD上使用Postgres时，这毫无意义。分拣存储位置的计算可能是wast。因为SSD是仅随机访问的设备（如果我没有弄错的话）

我还做了一些测试，通过打开/关闭

enable\u 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

确实有明显的改善

---

启用\u位图扫描时，规划器使用BitmapHeapScan+BitmapIndexScan。禁用时，规划人员只选择索引Scan。

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