Pourquoi ne PostgreSQL effectuer l'analyse séquentielle sur colonne indexée?

Question

Exemple très simple - une table, un index, une requête:

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

me donne:

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

Pourquoi il n'effectue PAS d'analyse d'index à la place? Ce qui me manque?

Answer 1

Si la sélection retourne plus que d'environ 5 à 10% de toutes les lignes dans la table, un balayage séquentiel est beaucoup plus rapide qu'une analyse d'index.

C'est parce qu'un index scan nécessite plusieurs opérations d'e / s pour chaque ligne (rechercher la ligne dans l'index, puis récupérer la ligne dans le tas). Alors qu'une analyse séquentielle ne nécessite qu'un seul IO pour chaque ligne - ou même moins, car un bloc (page) sur le disque contient plus d'une ligne, plus d'une rangée peuvent être récupérées avec une seule opération e / s.

Btw: c'est vrai pour d'autres SGBD ainsi - quelques optimisations comme "indice ne scanne" prise à part (mais pour un SELECT * il est très peu probable une telle SGBD serait aller pour un indice de "scanner")

Answer 2

Avez-vous ANALYSER la table/base de données? Et que dire de la statistique? Quand il y a beaucoup de dossiers où year > 2009, un balayage séquentiel peut être plus rapide qu'une analyse d'index.