PostgreSQL
Consultas lentas y diagnóstico
Método para diagnosticar consultas lentas con métricas, pg_stat_statements, EXPLAIN ANALYZE, waits, locks y comparación entre estimaciones y ejecución.
- Última actualización
- Actualizada
- Nivel
- Profundización
PostgreSQL
Método para diagnosticar consultas lentas con métricas, pg_stat_statements, EXPLAIN ANALYZE, waits, locks y comparación entre estimaciones y ejecución.
Una consulta “lenta” puede estar ejecutando trabajo costoso o simplemente esperando. El diagnóstico empieza separando queue, locks, I/O, CPU, red y cliente antes de modificar SQL o índices.
Proceso disciplinado:
confirmar impacto y periodo
→ identificar query/endpoint/parámetros
→ separar espera de ejecución
→ obtener plan y métricas
→ formular hipótesis
→ probar cambio
→ validar sistema completoPregunta:
Una captura aislada puede no representar la regresión.
Usa:
pg_stat_statements por tiempo total/medio/max/calls.application_name.pg_stat_activity durante el incidente.Necesitas parámetros representativos porque la selectividad puede cambiar el plan.
Si una operación tarda 20 s y consume poca CPU:
Un plan perfecto no resuelve una transacción bloqueadora.
SELECT
pid, application_name, state,
wait_event_type, wait_event,
xact_start, query_start,
pg_blocking_pids(pid) AS blockers,
query
FROM pg_stat_activity
WHERE datname = current_database();Identifica el blocker raíz, no solo el proceso inmediatamente anterior. Una cadena puede tener una única transacción antigua al comienzo.
EXPLAIN (ANALYZE, BUFFERS, WAL, SETTINGS, VERBOSE)
SELECT ...;ANALYZE ejecuta. Para writes, replica efectos dentro de una transacción solo si triggers/side effects son reversibles y el entorno lo permite. En producción, usa copia, read-only equivalent o plan estimado cuando el riesgo es alto.
Busca:
loops multiplicando trabajo.La primera gran misestimación de abajo hacia arriba suele explicar decisiones posteriores.
Causas:
Soluciones:
Un índice ayuda si reduce páginas/filas o aporta orden. Antes de crearlo:
predicados + orden + frecuencia + selectividad + write costVerifica duplicados existentes. Crea concurrentemente cuando corresponda y observa réplica/WAL.
Spill a disco puede resolverse con:
SET LOCAL work_mem para ese job.No subas work_mem global automáticamente.
pg_stat_statements puede mostrar una query rápida con millones de calls. El problema está en patrón de aplicación:
1 query parents + N queries childrenSoluciones: join, batch ANY, DataLoader, prefetch o endpoint diferente.
Compara valores:
status=pending → 10 filas
status=paid → 10M filasUn generic plan puede servir a ninguno. Prueba custom/generic, stats MCV y statements separadas.
Cambios frecuentes:
SELECT */payload mayor.Compara query text, plan y dataset antes/después.
Reducir filas, preagregar, reescribir predicate, eliminar N+1.
Índice, constraint, tipo, partitioning/read model.
Analyze/extended stats.
Locks cortos, orden, timeout, batch.
Pool, storage, vacuum, memory local, scheduling.
Cache/materialized view/replica/async job.
Después del cambio mide:
Una mejora local puede degradar ingest o otra query.
Opciones de menor riesgo:
Reiniciar borra evidencia y puede no corregir la causa.
loops importa?Integración de PostgreSQL con aplicaciones transforma drivers, transacciones y errores en contratos de backend confiables.