El índice de la clave principal no se usa en la unión simple

Tengo las siguientes definiciones de tabla e índice:

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);

¿Por qué no se utiliza ninguno de los índices en munkalap_id en la siguiente consulta?

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

Es lo mismo incluso si agrego un filtro:

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

Muchas personas han escuchado la orientación de que "los escaneos secuenciales son malos" y buscan eliminarlos de sus planes, pero no es tan simple. Si una consulta va a cubrir todas las filas de una tabla, un análisis secuencial es la forma más rápida de obtener esas filas. Esta es la razón por la que su consulta de combinación original utilizaba la exploración seq, porque se requerían todas las filas en ambas tablas.

Al planificar una consulta, el planificador de Postgres estima los costos de varias operaciones (cálculo, secuencial y E / S aleatoria) bajo diferentes esquemas posibles, y elige el plan que estima que tiene el costo más bajo. Al hacer IO desde almacenamiento rotativo (discos), IO aleatorio suele ser sustancialmente más lento que IO secuencial, la configuración de pg predeterminada para random_page_cost y seq_page_cost estima una diferencia de 4: 1 en el costo.

Estas consideraciones entran en juego cuando se considera un método de combinación o filtro que utiliza un índice frente a uno que escanea secuencialmente una tabla. Cuando se usa un índice, el plan puede encontrar una fila rápidamente a través del índice, luego debe tener en cuenta una lectura de bloque aleatorio para resolver los datos de la fila. En el caso de su segunda consulta que agregó un predicado de filtrado WHERE NOT lezarva, puede ver cómo esto afectó las estimaciones de planificación en los resultados de EXPLAIN ANALYZE. El planificador estima 1006 filas resultantes de la unión (que coincide bastante con el conjunto de resultados real de 964). Dado que la tabla más grande munkalap_lepes contiene aproximadamente 38K filas, el planificador ve que la unión tendrá que acceder a aproximadamente 1006/38046 o 1/38 de las filas de la tabla. También sabe que el ancho de fila promedio es de 214 bytes y un bloque es de 8K, por lo que hay aproximadamente 38 filas / bloque.

Con estas estadísticas, el planificador considera probable que la unión tenga que leer todos o la mayoría de los bloques de datos de la tabla. Dado que las búsquedas de índice tampoco son gratuitas, y el cálculo para escanear un bloque que evalúa una condición de filtro es muy barato en relación con IO, el planificador ha elegido escanear secuencialmente la tabla y evitar la sobrecarga del índice y las lecturas aleatorias mientras calcula el escaneo de secuencia Será más rápido.

En el mundo real, los datos a menudo están disponibles en la memoria a través de la memoria caché de la página del sistema operativo, por lo que no todas las lecturas de bloque requieren IO. Puede ser bastante difícil predecir qué tan efectivo será un caché para una consulta dada, pero el planificador de Pg usa algunas heurísticas simples. El valor de configuración efectivo_caché_tamaño informa a los planificadores de la probabilidad de incurrir en costos reales de E / S. Un valor mayor hará que calcule un costo menor para IO aleatorio y, por lo tanto, puede sesgarlo hacia un método impulsado por índice en una exploración secuencial.

Está recuperando todas las filas de ambas tablas, por lo que no hay un beneficio real al usar una exploración de índice. Una exploración de índice solo tiene sentido si selecciona solo unas pocas filas de una tabla (generalmente menos del 10% -15%)