Ler um plano em profundidade com EXPLAIN (ANALYZE, BUFFERS, SETTINGS, WAL)
PostgreSQLDesempenhoComando
-- ANALYZE really executes the statement: run DML inside a transaction and roll it back
BEGIN;
EXPLAIN (ANALYZE, BUFFERS, SETTINGS, WAL, VERBOSE)
UPDATE customer SET balance = balance + 1 WHERE city = 'Ankara';
ROLLBACK;
-- For SELECT
EXPLAIN (ANALYZE, BUFFERS, SETTINGS)
SELECT name FROM customer ORDER BY name DESC LIMIT 10 OFFSET 1000;O que faz
Retorna o plano com estatísticas reais de execução: BUFFERS mostra por nó os blocos shared hit/read/dirtied e temp, SETTINGS mostra parâmetros fora do padrão que afetam o planejamento, WAL mostra os registros/bytes de WAL gerados.
Quando usar
Para analisar a diferença entre linhas estimadas e reais, sorts/hashes que transbordam para disco (Sort Method: external merge, temp read/written) e o custo de WAL de DML.
Atenção
ANALYZE realmente executa o comando; sempre rode DML dentro de BEGIN/ROLLBACK (triggers e incrementos de sequence ainda acontecem). Dicas de leitura: uma diferença de 10x ou mais entre 'rows' estimado e 'actual rows' aponta para um problema de estatísticas; em nós dentro de loops, tempo e linhas são por loop, multiplique por loops para o total; 'Heap Fetches' alto em um Index Only Scan significa visibility map desatualizado, e 'Workers Planned' > 'Workers Launched' significa que o pool de workers se esgotou. Use TIMING OFF onde o overhead de tempo for alto; COSTS OFF também esconde a seção de JIT.
Relacionados
- Encontrar as consultas mais caras (pg_stat_statements: tempo total e médio)
- Encontrar as consultas que geram I/O de disco, arquivos temporários e WAL (pg_stat_statements)
- Zerar as estatísticas do pg_stat_statements (todas ou de uma única consulta)
- Registrar os planos de execução de consultas lentas com auto_explain
- Detectar regressões de plano por queryid (comparação de snapshots do pg_stat_statements)
- Verificar a capacidade de consulta paralela e o uso atual de workers