优化 – 在postgres seq扫描和位图堆扫描有什么区别？

基本上，顺序扫描将转到实际行，并开始从行1读取，并继续，直到满足查询(这可能不是整个表，例如在limit的情况下)

位图堆扫描意味着PostgreSQL发现要获取的一小部分行(例如，从索引)，并且将只获取那些行。这当然会有更多的寻求，所以只有当它需要一个小子集的行更快。

举个例子：

create table test (a int primary key,b int unique,c int);
insert into test values (1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5);

现在，我们可以很容易得到一个seq扫描：

explain select * from test where a != 4

                       QUERY PLAN                        
---------------------------------------------------------
 Seq Scan on test  (cost=0.00..34.25 rows=1930 width=12)
   Filter: (a <> 4)

它做了一个顺序扫描，因为它估计它将抓住绝大多数的表;寻求这样做(而不是一个大的，无私的阅读)将是愚蠢的。

现在，我们可以使用索引：

explain select * from test where a = 4 ;
                              QUERY PLAN                              
----------------------------------------------------------------------
 Index Scan using test_pkey on test  (cost=0.00..8.27 rows=1 width=4)
   Index Cond: (a = 4)

最后，我们可以得到一些位图操作：

explain select * from test where a = 4 or a = 3;
                                  QUERY PLAN                                  
------------------------------------------------------------------------------
 Bitmap Heap Scan on test  (cost=8.52..13.86 rows=2 width=12)
   Recheck Cond: ((a = 4) OR (a = 3))
   ->  BitmapOr  (cost=8.52..8.52 rows=2 width=0)
         ->  Bitmap Index Scan on test_pkey  (cost=0.00..4.26 rows=1 width=0)
               Index Cond: (a = 4)
         ->  Bitmap Index Scan on test_pkey  (cost=0.00..4.26 rows=1 width=0)
               Index Cond: (a = 3)

我们可以这样读：

>为a = 4创建我们想要的行的位图。 (位图索引扫描)
>为a = 3创建我们想要的行的位图。 (位图索引扫描)
>或者将两个位图组合在一起(BitmapOr)
>在表中查找这些行(位图堆扫描)并检查以确保a = 4或a = 3(重新检查cond)

[是的，这些查询计划是愚蠢的，但这是因为我们未能分析测试，如果我们分析它，他们都是顺序扫描，因为有5个小行]