Something Got Better For Partitioning in v18 Unless Reverted
summary
Shows that Postgres v18 makes generic plans practical for partitioned tables by moving partition locking until after runtime pruning, so the planner no longer locks every partition a generic plan references. Measured with pgbench prepared mode and plan_cache_mode=force_generic_plan, benchmarks show TPS stays nearly flat as partitions increase versus steep decline on v17. Change is a single commit that defers locking until after execution-time pruning; it substantially reduces partition-related overhead though a small residual degradation remains.
AI-written summary · about
related talks
26mPartitioning your Postgres tables for 20x better performance
30mOvercoming Performance Hurdles in Postgres Partitioned Tables
28mFast-path locking improvements in PG18
28mWhat’s new in the Postgres 18 query planner / optimizer
50mPerformance Improvements of Partitioning: Past and Future
26mMy Postgres partitioning cookbook
32mFast-path locking improvements in PG18
42mPushing Postgres Forward: From Open Source Contributions to Intelligent T