ANALYZE & Autoanalyze

Os workers do Autovacuum executam ANALYZE quando as tabelas mudam o suficiente. ETL em massa, migrações e tabelas "hot" com dados desbalanceados ainda precisam de ANALYZE manual no PostgreSQL 18.4 antes de confiar em novos planos.

Receita

Cartão de referência rápida - pronto para copiar e colar.

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

Quando usar: Após grandes operações de COPY, anexação de partições ou regressões de plano em uma tabela que "deveria" ser analisada automaticamente.

Exemplo de Trabalho

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 limite: analyze manual após carga em massa
ANALYZE VERBOSE orders;
 
EXPLAIN (ANALYZE)
SELECT count(*) FROM orders WHERE status = 'pending';

O que isso demonstra:

• Monitoramento de n_mod_since_analyze
• Analyze manual pós-carga
• Estabilidade do plano após atualização das estatísticas

Mergulho Profundo

Como Funciona

• O Autoanalyze é acionado quando n_mod_since_analyze excede os limites de inserção/atualização/exclusão com base em autovacuum_analyze_scale_factor (padrão 0.1) mais autovacuum_analyze_threshold.
• ANALYZE adquire um lock compartilhado (share lock); geralmente breve em tabelas grandes devido à amostragem.
• ANALYZE t (col) direcionado a colunas acelera as execuções quando apenas uma coluna desbalanceada mudou.
• VACUUM (ANALYZE) combina limpeza de visibilidade e estatísticas (prefira ajuste separado em produção).

Exemplo de Ajuste de Limite

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

Quando o ANALYZE Manual é Necessário

Armadilhas

• Desabilitar autovacuum para "reduzir carga" - As estatísticas decaem junto com o bloat. Correção: Ajuste os limites por tabela, nunca globalmente desativado.
• Analisar durante o pico sem necessidade - Pico de I/O em tabelas enormes. Correção: Agendar após ETL; usar listas de colunas.
• Assumir que CREATE INDEX atualiza estatísticas - Estatísticas de índice são diferentes; estatísticas da tabela podem estar desatualizadas. Correção: ANALYZE na tabela após a construção do índice.
• Ignorar tabelas herdadas - O pai particionado pode precisar de ANALYZE nos filhos. Correção: ANALYZE ONLY vs comportamento padrão conforme a documentação.
• Comparar planos antes do analyze - Falsos negativos na utilidade do índice. Correção: Padronizar o analyze no harness de teste de performance.

Alternativas

FAQs

Relacionados

• Noções Básicas de Estatísticas - O que é coletado
• Estatísticas Estendidas - Além das estatísticas por coluna
• Ajuste de Autovacuum - Configurações de workers compartilhados
• Melhores Práticas de Estatísticas - Checklist da equipe

Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, e PostGIS 3.5+.