ANALYZE y Autoanalyze

Los workers de Autovacuum ejecutan ANALYZE cuando las tablas cambian lo suficiente. Las cargas masivas de ETL, las migraciones y las tablas "hot" con datos sesgados todavía necesitan un ANALYZE manual en PostgreSQL 18.4 antes de confiar en los nuevos planes.

Receta

Tarjeta de referencia rápida - lista para copiar y pegar.

ANALYZE VERBOSE orders;
ANALYZE orders (status, created_at);

Cuándo usar esto: Después de una carga masiva (COPY), adjuntar una partición, o regresiones de planes en una tabla que "debería" ser analizada automáticamente.

Ejemplo de Trabajo

CREATE TABLE orders (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  status text NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);
 
INSERT INTO orders (status)
SELECT 'pending' FROM generate_series(1, 500000);
 
SELECT relname, last_analyze, last_autoanalyze, n_mod_since_analyze
FROM pg_stat_user_tables
WHERE relname = 'orders';
 
-- Simular umbral: análisis manual después de carga masiva
ANALYZE VERBOSE orders;
 
EXPLAIN (ANALYZE)
SELECT count(*) FROM orders WHERE status = 'pending';

Lo que esto demuestra:

• Monitorización de n_mod_since_analyze
• Análisis manual post-carga
• Estabilidad del plan después de la actualización de estadísticas

Análisis Profundo

Cómo Funciona

• Autoanalyze se activa cuando n_mod_since_analyze supera los umbrales de inserción/actualización/eliminación basados en autovacuum_analyze_scale_factor (por defecto 0.1) más autovacuum_analyze_threshold.
• ANALYZE toma un bloqueo compartido (share lock); usualmente breve en tablas grandes debido al muestreo.
• ANALYZE t (col) dirigido a columnas acelera las ejecuciones cuando solo una columna sesgada ha cambiado.
• VACUUM (ANALYZE) combina la limpieza de visibilidad y las estadísticas (preferir ajuste separado en producción).

Ejemplo de Ajuste de Umbrales

ALTER TABLE orders SET (
  autovacuum_analyze_scale_factor = 0.02,
  autovacuum_analyze_threshold = 1000
);

Cuándo se Requiere un ANALYZE Manual

Trampas Comunes

• Desactivar autovacuum para "reducir la carga" - Las estadísticas se degradan junto con la fragmentación (bloat). Solución: Ajustar umbrales por tabla, nunca globalmente desactivado.
• Analizar durante horas pico sin necesidad - Pico de I/O en tablas enormes. Solución: Programar después de ETL; usar listas de columnas.
• Asumir que CREATE INDEX actualiza estadísticas - Las estadísticas de índices son diferentes; las estadísticas de la tabla pueden estar desactualizadas. Solución: ANALYZE la tabla después de la creación del índice.
• Ignorar tablas heredadas - El padre particionado puede necesitar ANALYZE en los hijos. Solución: ANALYZE ONLY vs comportamiento por defecto según la documentación.
• Comparar planes antes del análisis - Falsos negativos en la utilidad del índice. Solución: Estandarizar el análisis en el sistema de pruebas de rendimiento.

Alternativas

Preguntas Frecuentes

Relacionado

• Estadísticas Básicas - Qué se recopila
• Estadísticas Extendidas - Más allá de las estadísticas por columna
• Ajuste de Autovacuum - Configuración compartida de workers
• Mejores Prácticas de Estadísticas - Lista de verificación del equipo

Versiones de la Pila: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.