Index sur la clé primaire non utilisé dans la jointure simple

J'ai les définitions de table et d'index suivantes:

CREATE TABLE munkalap (
    munkalap_id serial PRIMARY KEY,
    ...
);

CREATE TABLE munkalap_lepes (
    munkalap_lepes_id serial PRIMARY KEY,
    munkalap_id integer REFERENCES munkalap (munkalap_id),
    ...
);

CREATE INDEX idx_munkalap_lepes_munkalap_id ON munkalap_lepes (munkalap_id);

Pourquoi aucun des index de munkalap_id n'est-il utilisé dans la requête suivante?

EXPLAIN ANALYZE SELECT ml.* FROM munkalap m JOIN munkalap_lepes ml USING (munkalap_id);

QUERY PLAN
Hash Join  (cost=119.17..2050.88 rows=38046 width=214) (actual time=0.824..18.011 rows=38046 loops=1)
  Hash Cond: (ml.munkalap_id = m.munkalap_id)
  ->  Seq Scan on munkalap_lepes ml  (cost=0.00..1313.46 rows=38046 width=214) (actual time=0.005..4.574 rows=38046 loops=1)
  ->  Hash  (cost=78.52..78.52 rows=3252 width=4) (actual time=0.810..0.810 rows=3253 loops=1)
        Buckets: 1024  Batches: 1  Memory Usage: 115kB
        ->  Seq Scan on munkalap m  (cost=0.00..78.52 rows=3252 width=4) (actual time=0.003..0.398 rows=3253 loops=1)
Total runtime: 19.786 ms

C'est la même chose même si j'ajoute un filtre:

EXPLAIN ANALYZE SELECT ml.* FROM munkalap m JOIN munkalap_lepes ml USING (munkalap_id) WHERE NOT lezarva;

QUERY PLAN
Hash Join  (cost=79.60..1545.79 rows=1006 width=214) (actual time=0.616..10.824 rows=964 loops=1)
  Hash Cond: (ml.munkalap_id = m.munkalap_id)
  ->  Seq Scan on munkalap_lepes ml  (cost=0.00..1313.46 rows=38046 width=214) (actual time=0.007..5.061 rows=38046 loops=1)
  ->  Hash  (cost=78.52..78.52 rows=86 width=4) (actual time=0.587..0.587 rows=87 loops=1)
        Buckets: 1024  Batches: 1  Memory Usage: 4kB
        ->  Seq Scan on munkalap m  (cost=0.00..78.52 rows=86 width=4) (actual time=0.014..0.560 rows=87 loops=1)
              Filter: (NOT lezarva)
Total runtime: 10.911 ms

Beaucoup de gens ont entendu dire que "les analyses séquentielles sont mauvaises" et cherchent à les éliminer de leurs plans, mais ce n'est pas si simple. Si une requête doit couvrir chaque ligne d'un tableau, une analyse séquentielle est le moyen le plus rapide d'obtenir ces lignes. C'est pourquoi votre requête de jointure d'origine a utilisé l'analyse séquentielle, car toutes les lignes des deux tables étaient requises.

Lors de la planification d'une requête, le planificateur de Postgres estime les coûts de diverses opérations (calcul, séquentiel et E / S aléatoires) selon différents schémas possibles, et choisit le plan qu'il estime comme ayant le coût le plus bas. Lorsque vous effectuez des E / S à partir d'un stockage rotatif (disques), les E / S aléatoires sont généralement beaucoup plus lentes que les E / S séquentielles, la configuration pg par défaut pour random_page_cost et seq_page_cost estime une différence de coût de 4: 1.

Ces considérations entrent en jeu lorsque l'on considère une méthode de jointure ou de filtrage qui utilise un index par rapport à un qui analyse séquentiellement une table. Lorsque vous utilisez un index, le plan peut trouver une ligne rapidement via l'index, puis avoir à prendre en compte une lecture aléatoire de bloc pour résoudre les données de ligne. Dans le cas de votre deuxième requête qui a ajouté un prédicat de filtrage WHERE NOT lezarva, vous pouvez voir comment cela a affecté les estimations de planification dans les résultats EXPLAIN ANALYZE. Le planificateur estime 1006 lignes résultant de la jointure (ce qui correspond assez étroitement à l'ensemble de résultats réel de 964). Étant donné que la plus grande table munkalap_lepes contient environ 38K lignes, le planificateur voit que la jointure devra accéder à environ 1006/38046 ou 1/38 des lignes de la table. Il sait également que la largeur de ligne moyenne est de 214 octets et qu'un bloc est de 8 Ko, il y a donc environ 38 lignes / bloc.

Avec ces statistiques, le planificateur considère qu'il est probable que la jointure devra lire tout ou la plupart des blocs de données de la table. Étant donné que les recherches d'index ne sont pas gratuites non plus et que le calcul pour analyser un bloc évaluant une condition de filtre est très bon marché par rapport aux entrées-sorties, le planificateur a choisi d'analyser séquentiellement la table et d'éviter les frais généraux d'index et les lectures aléatoires lors du calcul de l'analyse séquentielle. sera plus rapide.

Dans le monde réel, les données sont souvent disponibles en mémoire via le cache de page du système d'exploitation, et donc chaque lecture de bloc ne nécessite pas d'E / S. Il peut être assez difficile de prédire l'efficacité d'un cache pour une requête donnée, mais le planificateur Pg utilise quelques heuristiques simples. La valeur de configuration effective_cache_size informe les planificateurs des estimations de la probabilité d'engager des coûts d'E / S réels. Une valeur plus élevée lui fera estimer un coût inférieur pour les entrées-sorties aléatoires et peut donc le biaiser vers une méthode pilotée par index sur un balayage séquentiel.

Vous récupérez toutes les lignes des deux tables, il n'y a donc aucun avantage réel à utiliser une analyse d'index. Une analyse d'index n'a de sens que si vous ne sélectionnez que quelques lignes dans une table (généralement moins de 10% -15%)