http://www.postgresql.org/docs/8.2/static /using-explain.html
基本的に、シーケンシャルスキャンは実際の行に移動し、行1から読み取りを開始し、クエリが満たされるまで続行します（これは、制限の場合など、テーブル全体ではない場合があります）
ビットマップヒープスキャンは、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に必要な行のビットマップを作成します。 （ビットマップインデックススキャン）
- または2つのビットマップを一緒に（BitmapOr）
- テーブルでこれらの行を検索し（ビットマップヒープスキャン）、a=4またはa=3であることを確認します（条件を再確認します）
[はい、これらのクエリプランはばかげていますが、それはtestの分析に失敗したためです。 分析した場合、5つの小さな行があるため、すべてシーケンシャルスキャンになります]