Verificar que el partition pruning funciona (en tiempo de planificación y de ejecución)

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';

Qué hace

Compara el pruning en tiempo de planificación, el pruning en tiempo de ejecución con un plan genérico ('Subplans Removed: N') y cómo se pierde el pruning cuando se aplica una función a la clave de partición.

Cuándo usarlo

Cuando las consultas sobre una tabla particionada son más lentas de lo esperado, el plan recorre todas las particiones o la aplicación usa un ORM/prepared statements.

Precaución

Aplicar una función o un cast a la clave de partición (date_trunc(created_at), created_at::text) deshabilita el pruning; escriba la condición como un rango sobre la clave. Con un plan genérico, el pruning ocurre al arrancar el executor y solo se ve como 'Subplans Removed'; para expresiones STABLE como now() también es visible en EXPLAIN sin ANALYZE. Con enable_partition_pruning = off no hay ningún pruning. Con muchas particiones, mida también el Planning Time.