PostgreSQL 17 vs 18: Side‑by‑Side Performance Wins in Real‑World Queries
summary
Identical Azure VMs run Postgres 17 and 18 with EXPLAIN ANALYZE, seven measured runs and one warmup so timings are cache‑hot; results show concrete wins: a 43% cut in OR‑chain queries, a B-tree skip scan turning 121 ms into 0.07 ms (≈1,741×), self‑join elimination reducing 6.29 ms to 1.28 ms (≈5×) enabled by enable_self_join_elimination, GROUP‑BY pruning on unique indexes cutting 13 ms to 0.05 ms, and a 1.5× faster EXCEPT via cleaned hash set execution.
AI-written summary · about
chapters (10)
- 0:00Music & introduction
- 0:32Test setup and fair comparison methodology
- 1:48Realistic datasets and workload modeling
- 2:33Or-to-any transformation and query speedups
- 6:18B-tree skip scan: huge gains on composite indexes
- 13:02Self-join elimination in ORM-generated queries
- 17:39Smarter group by pruning with unique indexes
- 20:01Faster EXCEPT queries and cleaner execution plans
- 23:08Summary of 5 major performance improvements in PG 18
- 25:01When upgrading to Postgres 18 makes sense
related talks
52mBoosting Typical Query Patterns: PostgreSQL 18's Performance Enhancements
28mWhat’s new in the Postgres 18 query planner / optimizer
42mPushing Postgres Forward: From Open Source Contributions to Intelligent T
29mPerformance Archaeology - 20 years of improvements
16mAll the Postgres Things
30mOvercoming Performance Hurdles in Postgres Partitioned Tables
50mPerformance Archaeology
07mPostgreSQL in ever more critical environments