Improved Freezing in Postgres Vacuum: From Idea to Commit
summary
Postgres 18 adds eager scanning: instead of complex LSN histograms and interval models the implementation scans a bounded number of all-visible but not all-frozen pages during normal vacuums and tries to freeze them early. It limits work by region (32 MB), stops after a 20% success cap or when failures exceed a 3% failure threshold (the failure rate is tunable), and avoids shared-memory statistics. Result: fewer disruptive anti-wraparound aggressive vacuums, lower IO amplification, and more predictable autovacuum runtimes.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 1:08What is freezing in PostgreSQL
- 6:13Why freezing is hard to improve
- 13:19First attempts at adaptive freezing
- 21:28Challenges with LSN-based approaches
- 32:30Simpler solution for PostgreSQL 18
- 36:50Future directions for freezing
- 37:12Q&A session
related talks
19mVacuuming Enhancements in PostgreSQL 18: Faster, Smarter, More Predictable
49mA Detailed Understanding of MVCC and Autovacuum Internals in PostgreSQL 14
50mFraught Feedback: Trying and Failing to Implement Adaptive Behavior in Postgres
55mUnderstanding Autovacuum
48mInside Postgres: why VACUUM matters
31m5 Wrong Hypotheses about PostgreSQL Multi-Transaction Locks
27mMaintaining Large Tables in PostgreSQL
47mAutoVacuum - Tuning and Monitoring