Vérifier que le partition pruning fonctionne (à la planification et à l'exécution)

Commande

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

Ce que fait la commande

Compare le pruning à la planification, le pruning à l'exécution avec un plan générique ('Subplans Removed: N'), et la perte du pruning lorsqu'une fonction est appliquée à la clé de partitionnement.

Quand l'utiliser

Lorsque les requêtes sur une table partitionnée sont plus lentes que prévu, que le plan parcourt toutes les partitions, ou que l'application utilise un ORM/des prepared statements.

Attention

Appliquer une fonction ou un cast à la clé de partitionnement (date_trunc(created_at), created_at::text) désactive le pruning ; écrivez la condition sous forme de plage sur la clé. Avec un plan générique, le pruning a lieu au démarrage de l'exécuteur et n'apparaît que sous 'Subplans Removed' ; pour les expressions STABLE comme now(), il est aussi visible dans EXPLAIN sans ANALYZE. Avec enable_partition_pruning = off, aucun pruning n'a lieu. Avec de nombreuses partitions, mesurez aussi le Planning Time.