EXPLAIN y ANALYZE

¿Alguna vez te has preguntado cómo la base de datos elige usar ese bonito índice que acabas de crear? Tan pronto como presiona Enter en una consulta (por ejemplo, una unión larga con un grupo encadenado), el Planificador de consultas calcula docenas de estrategias sobre la marcha para llevar a cabo la consulta y elige la que se cree, en teoría, que es más rápida.

Pero como desarrollador, debes poder mirar dentro de la mente oscura del Planificador de consultas.

EXPLICAR

Para descubrir cómo pretende proceder el Planificador, simplemente escriba la palabra mágica EXPLAIN al comienzo de su consulta.

EXPLAIN SELECT * FROM orders WHERE status = 'delivered';

¡El resultado no serán los pedidos! En su lugar, verá el plan en el resultado (con estadísticas estimadas):

Seq Scan on orders  (cost=0.00..25.88 rows=15 width=40)
  Filter: (status = 'delivered'::text)

Esto nos dice:

1. El Planificador utilizará un Seq Scan (lectura bruta secuencial de todo el disco). Malo si hay miles de millones de pedidos.
2. Estima que se devolverán ~15 filas y calcula el "costo" en ciclos de CPU precargados.

EXPLICAR ANALIZAR

Mientras EXPLAIN se basa en conjeturas algorítmicas (basadas en estadísticas globales calculadas en las últimas horas sobre los datos), EXPLAIN ANALYZE en realidad ejecuta la consulta de verdad (y espera los resultados lógicos completos), comparando el tiempo real transcurrido en términos matemáticamente absolutos.

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 90;

Index Scan using idx_orders_cust on orders  (cost=0.15..8.13 rows=4 width=40) (actual time=0.012..0.015 rows=4 loops=1)
  Index Cond: (customer_id = 90)
Planning Time: 0.081 ms
Execution Time: 0.033 ms

¡Hurra! Aquí aprenderá que la base de datos ha decidido aplicar un Escaneo de índice en nuestro índice secundario idx_orders_cust, tomando un tiempo de ejecución microscópico de una milésima de segundo, omitiendo millones de filas sobre la marcha.

Tu turno

Obteniendo métricas veraces