Level: Advanced
This talk uses the recently committed eager scanning feature as a case study to walk through the Postgres feature development process. It’s meant to give prospective contributors a realistic look at what it takes to get a feature committed and to help users better understand how Postgres evolves and how they can benefit from these changes.
Anti-wraparound vacuums are one of the most consistent Postgres user complaints. This talk explains how freeze debt accumulates, how it varies based on table access patterns, and how Postgres attempts to manage it.
Eager scanning started as a proposal on pgsql-hackers to preemptively freeze modified pages using per-table access pattern statistics.
Over years of discussion and experimentation (including evaluating and discarding many empirical models and approaches), the shape of both the problem and solutions evolved. This talk dives into what made designing an adaptive feature in Postgres so difficult: extreme constraints, second-order effects, code complexity, and the sheer variety of workloads Postgres must support.
The final committed feature is simpler than the original idea: it eagerly scans all-visible but not all-frozen pages to amortize the cost of aggressive vacuums. It doesn’t try to predict access patterns or freeze lifespan, but it’s effective, maintainable, and is a step toward addressing the core problem.
Finally, the talk will explain how users can expect this change to reduce the frequency and impact of anti-wraparound vacuums in their own workloads.