Index Cond と Filter の違い（読む前に効く条件・読んだ後に捨てる条件）

同じ条件が、2 か所のどちらかに出る

WHERE に書いた条件は、実行計画ではIndex Cond 側か Filter 側かのどちらかに現れます。 この 2 つは効くタイミングが違います。

• Index Cond — インデックスを辿る段階で使う。読む行数そのものが減る
• Filter — 行を読んだあとに捨てる。読む量は減らない

同じクエリでも、インデックスの張り方でどちらに出るかが変わります。実際に並べます。

まず、2 つが並んで出ている計画を見る

id（主キー・インデックスあり）とgrade（インデックス無し）で絞ります。

SELECT * FROM members WHERE id BETWEEN 1000 AND 1200 AND grade = 'gold';

 Index Scan using members_pkey on members  (cost=0.42..14.26 rows=71 width=34) (actual time=0.012..0.028 rows=67.00 loops=1)
   Index Cond: ((id >= 1000) AND (id <= 1200))
   Filter: (grade = 'gold'::text)
   Rows Removed by Filter: 134
   Index Searches: 1
 Planning Time: 0.292 ms
 Execution Time: 0.054 ms

2 つが上下に並んでいます。

• Index Cond: ((id >= 1000) AND (id <= 1200)) — インデックスを辿る段階で使われた条件
• Filter: (grade = 'gold') — 行を読んでから判定した条件
• Rows Removed by Filter: 134 — 201 行読んで134 行を捨てた（返したのは 67 行）

id の側はインデックスが範囲を直接絞れるので、そもそも 201 行しか読んでいません。grade の側はインデックスが無いので、201 行すべてを読んでから 134 行を捨てています。これが「読む前に効く」と「読んだあとに捨てる」の違いです。

Bitmap になると、条件が 2 つのノードに分かれる

-- members(city) にだけインデックスがある
SELECT * FROM members WHERE city = 'city-7' AND grade = 'gold';

 Bitmap Heap Scan on members  (cost=113.01..4431.51 rows=3346 width=34) (actual time=0.697..9.094 rows=3333.00 loops=1)
   Recheck Cond: (city = 'city-7'::text)
   Filter: (grade = 'gold'::text)
   Rows Removed by Filter: 6667
   Heap Blocks: exact=4167
   ->  Bitmap Index Scan on members_city_idx  (cost=0.00..112.17 rows=10100 width=0) (actual time=0.417..0.417 rows=10000.00 loops=1)
         Index Cond: (city = 'city-7'::text)
         Index Searches: 1
 Planning Time: 0.202 ms
 Execution Time: 9.276 ms

条件が 2 つのノードに散っています。探すときは子まで見てください。

• 子の Bitmap Index Scan に Index Cond: (city = 'city-7') — これが本物の Index Cond。 インデックスを辿って「どのページを読むか」を決めている
• 親の Bitmap Heap Scan に Recheck Cond: (city = 'city-7') — 同じ条件をもう一度書いたもの。 ビットマップが粗くなったときに備えた確認用で、「読む前に効いている」側という点は Index Cond と同じ
• Filter: (grade = 'gold') と Rows Removed by Filter: 6667 — こちらは変わらず読んだあとに捨てている側

10,000 行読んで 3,333 行しか使っていません。3 分の 2 が無駄読みです。

両方を含む複合インデックスを張ると

CREATE INDEX members_city_grade_idx ON members (city, grade);

 Bitmap Heap Scan on members  (cost=47.00..4234.56 rows=3373 width=34) (actual time=0.452..3.415 rows=3333.00 loops=1)
   Recheck Cond: ((city = 'city-7'::text) AND (grade = 'gold'::text))
   Heap Blocks: exact=3333
   ->  Bitmap Index Scan on members_city_grade_idx  (cost=0.00..46.15 rows=3373 width=0) (actual time=0.242..0.243 rows=3333.00 loops=1)
         Index Cond: ((city = 'city-7'::text) AND (grade = 'gold'::text))
         Index Searches: 1
 Planning Time: 0.237 ms
 Execution Time: 3.518 ms

Filter の行が消えました。代わりにRecheck Cond（と子の Index Cond）に両方の条件が乗っています。Rows Removed by Filter も出ていません。捨てる行がゼロになったということです。

効果は Heap Blocks の行に出ています。これは実際に読んだページ数です。

• 単一インデックス: Heap Blocks: exact=4167
• 複合インデックス: Heap Blocks: exact=3333

4,167 ページ → 3,333 ページ。20% 減りました。捨てる行が無くなったぶん、触るページも減っています。

読む量が減った結果は、実行時間にも出ています。同じ計画の Execution Time が 9.3 ミリ秒 → 3.5 ミリ秒（2.6 倍）。 ページを 20% 減らしただけに見えて、行を捨てる処理そのものが無くなっているぶん差が大きく出ます。 複合インデックスの列順の話は複合インデックスに。

3 つを並べると、捨てている量の差が見える

Rows Removed by Filter の読み方

この数字が「無駄読みの量」です。大きければ大きいほど、インデックスを見直す価値があります。

ただし絶対値では判断できません。1 万行捨てていても、それが全体の 1% なら気にする必要はありません。返した行数と並べて見ます。

• 返した行 3,333 / 捨てた行 6,667 → 3 分の 2 が無駄。直す価値がある
• 返した行 100 万 / 捨てた行 1,000 → 気にしなくてよい

インデックスが効いているかの判定にも使える

「インデックスを貼ったのに速くならない」ときは、まず条件が Index Cond 側に乗っているかを見ます。Filter 側に残っていれば、そのインデックスはその条件には効いていません。

乗らない理由はいくつもあります（列に関数をかけている、型が合っていない、 複合インデックスの左端を使っていない、など）。 一覧はインデックスが使われないときに何を見るかに まとまっています。