Introducción al análisis de rendimiento de consultas

Déjame empezar con una historia real. Imagina que curras como desarrollador en una pedazo de plataforma de e-commerce. Todo va perfecto, salvo por un detalle: el informe de ventas mensuales tarda tanto en cargar que tus usuarios pueden hacer otro pedido antes de que termine. Tú te pones nervioso, tu jefe se pone nervioso, el servidor de PostgreSQL hierve como una tetera, y todo huele a apocalipsis. Ahora imagina que pudieras encontrar la causa y arreglarla de un plumazo.

El análisis de rendimiento de consultas es como una revisión médica para tu PostgreSQL. Te ayuda a encontrar los “cuellos de botella” (dolores) y arreglarlos para mejorar la experiencia de usuario y ahorrar recursos del sistema.

¿Cómo funcionan las consultas por dentro en PostgreSQL?

Cuando escribes una consulta sencilla como:

SELECT * FROM products WHERE price > 100;

PostgreSQL no se lanza a sacar datos a lo loco. Primero analiza tu consulta, piensa cómo ejecutarla mejor y solo entonces se pone manos a la obra.

Fases principales de ejecución de consultas:

1. Parsing. PostgreSQL revisa tu consulta buscando errores de sintaxis y la convierte en una representación intermedia.
2. Optimización. El optimizador de consultas evalúa varias formas de ejecutar la consulta y elige la más “barata” (en tiempo y recursos).
3. Ejecución. El servidor sigue el plan elegido y saca los datos.

¿Qué es un “cuello de botella”?

Un “cuello de botella” es la parte de la consulta que ralentiza todo lo demás. Puede ser una operación que de repente se come la mayor parte del tiempo o recursos. Por ejemplo, si PostgreSQL hace un escaneo completo de la tabla (Seq Scan) en vez de usar un índice rápido, la consulta va lenta. O si hay muchos más datos de lo esperado y el servidor se tira la vida ordenando, uniendo o filtrando.

Estos momentos son los cuellos de botella — son los primeros que tienes que buscar y optimizar.

Herramientas para analizar el rendimiento de consultas

En PostgreSQL tienes varias herramientas potentes para identificar problemas en tus consultas:

1. EXPLAIN y EXPLAIN ANALYZE. Estos comandos te muestran cómo PostgreSQL planea ejecutar la consulta, o incluso la ejecutan para medir el rendimiento real.

• EXPLAIN: muestra el plan de ejecución de la consulta sin ejecutarla de verdad.
• EXPLAIN ANALYZE: ejecuta la consulta y muestra el plan real con métricas de tiempo reales.

Ejemplo de uso de EXPLAIN:

EXPLAIN SELECT * FROM products WHERE price > 100;

Salida:

Seq Scan on products  (cost=0.00..35.50 rows=5 width=72)
  Filter: (price > 100)

Aquí ves que la consulta hace un “Seq Scan” — escaneo completo de la tabla, que es ineficiente para tablas grandes.

2. pg_stat_statements. Es una extensión extra que lleva el registro de las consultas ejecutadas. Te muestra:

• Qué consultas se ejecutan en el servidor.
• Cuánto tiempo tarda cada consulta.
• Cuántas filas devuelve la consulta y cuántos recursos consume.

Para activar pg_stat_statements, tienes que:

1. Activar la extensión:

CREATE EXTENSION pg_stat_statements;

2. Configurar PostgreSQL: En el archivo postgresql.conf añade:

   shared_preload_libraries = 'pg_stat_statements'
   pg_stat_statements.track = all

3. Reinicia PostgreSQL.

Ahora puedes analizar las consultas:

SELECT * FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;

Esto te muestra las 5 consultas más “pesadas” ordenadas por tiempo total de ejecución.

3. Log de consultas lentas. Puedes configurar PostgreSQL para que registre en un log las consultas que tardan demasiado (por ejemplo, más de 1 segundo).

Para esto, en postgresql.conf pon:

log_min_duration_statement = 1000  # Tiempo en milisegundos (1 segundo)

Ahora las consultas lentas se guardarán en los logs de PostgreSQL.

Métricas clave para analizar el rendimiento

Cuando analices el rendimiento de tus consultas, fíjate en estas métricas clave:

1. Tiempo de ejecución. Es el tiempo que tarda la consulta en ejecutarse. Cuanto más rápido, mejor.
2. Cantidad de filas. Si tu consulta devuelve o escanea más filas de las que esperabas, puede ser un problema.
3. Uso de índices. Si la consulta debería usar un índice pero hace un escaneo secuencial (Seq Scan), es señal de que hay que optimizar.
4. Buffers y operaciones de disco. Las consultas que tiran mucho de disco van más lentas que las que usan datos en memoria.

¿Cómo se aplica esto en la práctica?

Ejemplo 1: Consulta lenta

Escribes una consulta para sacar todos los productos con precio mayor a 100:

SELECT * FROM products WHERE price > 100;

Ves que la consulta tarda demasiado. Usas EXPLAIN y ves:

Seq Scan on products  (cost=0.00..35.50 rows=5 width=72)
  Filter: (price > 100)

Problema: la consulta hace un escaneo completo porque no hay índice en la columna price.

Solución:

Crea un índice:

CREATE INDEX idx_price ON products(price);

Ahora la consulta usa Index Scan:

Index Scan using idx_price on products  (cost=0.15..8.25 rows=5 width=72)
  Index Cond: (price > 100)

Ejemplo 2: Detectando consultas lentas con pg_stat_statements

Con el comando:

SELECT query, total_time, calls
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 1;

Encuentras una consulta que se lleva mucho tiempo de ejecución. La abres con EXPLAIN ANALYZE, la arreglas y ya va más rápido.

Cuando empieces a usar EXPLAIN, pg_stat_statements y otras herramientas, tus consultas irán volando y tu servidor PostgreSQL funcionará como un reloj suizo. En la próxima lección nos meteremos en los detalles de los parámetros de EXPLAIN, como cost, rows y width, para que puedas leer los planes de ejecución como si fueran un libro abierto.