Cómo encontrar consultas lentas en PostgreSQL con pg_stat_statements
Antes de optimizar hay que medir. pg_stat_statements te dice qué consultas consumen más tiempo total; EXPLAIN ANALYZE te muestra por qué una consulta específica es lenta.
- 1
Habilita la extensión pg_stat_statements
Requiere agregar la librería a shared_preload_libraries en postgresql.conf y reiniciar. Luego se crea la extensión.
-- en postgresql.conf: shared_preload_libraries = 'pg_stat_statements' -- tras reiniciar: CREATE EXTENSION IF NOT EXISTS pg_stat_statements; - 2
Lista las consultas por tiempo total
Ordena por total_exec_time para ver dónde se va el tiempo del servidor. A veces una consulta rápida pero muy frecuente pesa más que una lenta aislada.
SELECT query, calls, total_exec_time, mean_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10; - 3
Analiza la consulta problemática con EXPLAIN ANALYZE
EXPLAIN ANALYZE ejecuta realmente la consulta y muestra tiempos y filas por nodo. En consultas de escritura envuélvelo en una transacción con ROLLBACK para no modificar datos.
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM pedidos WHERE cliente_id = 42; - 4
Reinicia las estadísticas cuando cambies algo
Después de aplicar una mejora, limpia los contadores para medir el efecto sobre una ventana nueva y comparar con claridad.
SELECT pg_stat_statements_reset();
// el error común
Leer EXPLAIN sin ANALYZE muestra el plan estimado, no el real: los costos son teóricos. Y usar EXPLAIN ANALYZE sobre un DELETE o UPDATE fuera de una transacción con ROLLBACK ejecuta el cambio de verdad.
// cuándo conviene un experto
Cuando el tiempo total se reparte entre decenas de consultas y no es obvio por dónde empezar, el análisis manual se vuelve largo. En dba.mx hacemos un tuning con evidencia: medimos, priorizamos por impacto y validamos cada cambio.
Agenda un Escaneo — desde USD $550Esta guía es orientativa y usa comandos de referencia. En producción, adapta a tu versión y prueba en un ambiente seguro primero.