Verificar se o partition pruning funciona (em tempo de planejamento e de execução)

Comando

SHOW enable_partition_pruning;

-- Plan-time pruning: only the relevant partition should appear in the plan
EXPLAIN (COSTS OFF)
SELECT count(*) FROM sales WHERE created_at >= DATE '2026-03-01' AND created_at < DATE '2026-04-01';

-- Run-time pruning: generic plan / parameterized query, "Subplans Removed: N"
PREPARE q_sales(date) AS SELECT count(*) FROM sales WHERE created_at = $1;
SET plan_cache_mode = force_generic_plan;
EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF) EXECUTE q_sales('2026-03-15');
RESET plan_cache_mode;
DEALLOCATE q_sales;

-- Pruning killer: a function on the key column scans every partition
EXPLAIN (COSTS OFF)
SELECT count(*) FROM sales WHERE date_trunc('month', created_at) = DATE '2026-03-01';

O que faz

Compara o pruning em tempo de planejamento, o pruning em tempo de execução com um plano genérico ('Subplans Removed: N') e como o pruning se perde quando uma função é aplicada à chave de partição.

Quando usar

Quando consultas em uma tabela particionada estão mais lentas que o esperado, o plano varre todas as partições ou a aplicação usa um ORM/prepared statements.

Atenção

Aplicar uma função ou cast à chave de partição (date_trunc(created_at), created_at::text) desabilita o pruning; escreva a condição como um intervalo sobre a chave. Com um plano genérico, o pruning acontece na inicialização do executor e aparece apenas como 'Subplans Removed'; para expressões STABLE como now() também é visível no EXPLAIN sem ANALYZE. Com enable_partition_pruning = off não há pruning algum. Com muitas partições, meça também o Planning Time.