The Runtime Theory

Vacuum Lifecycle: Reclaiming Dead Tuples

Follow a vacuum run: find dead tuple versions no snapshot can see, mark and sweep them, record reclaimable space in the free space map, and refresh statistics.

The Runtime Theory Team08 stages

trace / request.md

UPDATES LEAVEDEAD VERSIONSVACUUM RUN BEGINSVISIBILITYDECIDES FATEDEAD VERSIONSARE MARKEDPAGES ARECOMPACTEDFREE SPACEIS RECORDEDSTATISTICSARE REFRESHEDCYCLE REPEATS

readyUPDATE and DELETE under MVCC leave old tuple versions behind. A version becomes dead once no running transaction's snapshot can see it — its xmin is older than every active snapshot and its xmax is committed.

Vacuum is the bill for MVCC's zero-lock reads. Every UPDATE and DELETE leaves an old version behind, and nothing removes it until vacuum does. This diagram is one vacuum run: detect which versions are dead, mark them, sweep and compact pages, record free space, refresh statistics. The correctness constraint sits in the middle — a version visible to any still-running snapshot must survive, so vacuum's horizon is the oldest active snapshot, not the current time.

The ordering matters because each stage produces what the next consumes: detection feeds marking, marking creates the space that compaction rearranges, and compaction produces the free space map entries that make future inserts cheap. The last two stages are the quiet payoff — the free space map turns reclaimed space into reusable space, and fresh statistics keep the planner honest. Skip vacuum long enough and the table grows without bound, with dead versions dragging down every scan.