PostgreSQLがインデックス付きの列で順次スキャンを実行するのはなぜですか？

非常に単純な例-1つのテーブル、1つのインデックス、1つのクエリ：

CREATE TABLE book
(
  id bigserial NOT NULL,
  "year" integer,
  -- other columns...
);

CREATE INDEX book_year_idx ON book (year)

EXPLAIN
 SELECT *
   FROM book b
  WHERE b.year > 2009

私に与える：

Seq Scan on book b  (cost=0.00..25663.80 rows=105425 width=622)
  Filter: (year > 2009)

代わりにインデックススキャンを実行しないのはなぜですか？何が欠けていますか？

SELECTがテーブル内のすべての行の約5〜10％を超える場合、順次スキャンはインデックススキャンよりもはるかに高速です。

これは、インデックススキャンでは各行に複数の IO操作が必要なためです（インデックス内の行を検索し、ヒープから行を取得します）。一方、順次スキャンでは、行ごとに1つのIOのみが必要です。ディスク上のブロック（ページ）に複数の行が含まれているため、1回のIO操作で複数の行をフェッチできます。

ところで、これは他のDBMSにも当てはまります。「インデックスのみのスキャン」などの一部の最適化は除外されます（ただし、SELECT *の場合、このようなDBMSが「インデックスのみのスキャン」に使用することはほとんどありません）。

テーブル/データベースを分析しましたか？そして統計はどうですか？2009年を超えるレコードが多数ある場合、順次スキャンはインデックススキャンよりも高速になる可能性があります。

インデックススキャンでは、読み取りヘッドは1つの行から別の行にジャンプします（これは、次の物理ブロックの読み取りよりも1000倍遅いです（順次スキャン））。

したがって、（取得するレコードの数* 1000）がレコードの総数より少ない場合、インデックススキャンのパフォーマンスが向上します。

@a_horse_with_no_nameはそれをかなりよく説明しました。また、インデックススキャンを本当に使用したい場合は、通常、where句で境界付き範囲を使用する必要があります。例-年> 2019および年<2020。

多くの場合、統計はテーブルで更新されず、制約のために更新できない場合があります。この場合、オプティマイザーは、2019年を超える行数を知る必要はありません。したがって、完全な知識の代わりに順次スキャンを選択します。境界パーティションはほとんどの場合問題を解決します。