Prüfen, ob Partition Pruning funktioniert (Planungs- und Laufzeit)

Befehl

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

Was es tut

Vergleicht Pruning zur Planungszeit, Pruning zur Laufzeit mit einem generischen Plan ('Subplans Removed: N') und wie Pruning verloren geht, wenn eine Funktion auf den Partitionsschlüssel angewendet wird.

Wann einsetzen

Wenn Abfragen auf einer partitionierten Tabelle langsamer sind als erwartet, der Plan jede Partition scannt oder die Anwendung ein ORM/Prepared Statements nutzt.

Vorsicht

Eine Funktion oder ein Cast auf dem Partitionsschlüssel (date_trunc(created_at), created_at::text) deaktiviert Pruning; formuliere die Bedingung als Bereich auf dem Schlüssel. Mit einem generischen Plan erfolgt Pruning beim Start des Executors und zeigt sich nur als 'Subplans Removed'; bei STABLE-Ausdrücken wie now() ist es auch in EXPLAIN ohne ANALYZE sichtbar. Mit enable_partition_pruning = off findet gar kein Pruning statt. Bei vielen Partitionen auch die Planning Time messen.