パーティションプルーニングが機能していることを確認(計画時と実行時)
PostgreSQLパーティション化コマンド
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';概要
計画時のプルーニング、汎用計画での実行時プルーニング('Subplans Removed: N')、パーティションキーに関数を適用したときにプルーニングが失われる様子を比較する。
使用する場面
パーティション表へのクエリが想定より遅いとき、計画がすべてのパーティションをスキャンしているとき、アプリケーションがORM/プリペアドステートメントを使用しているときに。
注意
パーティションキーに関数やキャストを適用すると(date_trunc(created_at)、created_at::text)プルーニングが無効になる。条件はキーに対する範囲として記述する。汎用計画では、プルーニングはエグゼキュータの起動時に行われ、'Subplans Removed'としてのみ表示される。now()などのSTABLE式では、ANALYZEなしのEXPLAINでも確認できる。enable_partition_pruning = offではプルーニングはまったく行われない。パーティションが多い場合はPlanning Timeも測定する。