Delete and VACUUM — the file doesn't shrink
DELETE removes a cell pointer and adds the bytes to the page's freeblock chain — pages aren't compacted and aren't merged with siblings, so the file stays the same size until VACUUM rebuilds it (at ~2x disk transiently) or incremental_vacuum returns whole free pages to the OS.
Scene 5 ended with the tree symmetrically GROWING on insert. Junior intuition: it must symmetrically SHRINK on delete. It doesn't — and the difference is a half-step worth taking.
Scene 05a
Delete and VACUUM — the file doesn't shrink
- Watch
- Try it
- Predict
- Capture
Watch what 6 DELETEs do to leaf p17 and to the file. Cells gray out, the freeblock chain (red curve) snakes through them, the page-utilization meter drops to 40%. The DB FILE SIZE readout above the tree does NOT move.
Where this sits in Build a B-tree storage engine (SQLite-style)
Scene 05a of 11, in the Mutations act — Insert, split, delete — and why the file doesn't shrink.. DELETE doesn't shrink the file — pages get freeblocks but never merge; only VACUUM rebuilds the file (at 2x disk cost).
Up next. We've covered table B-trees end-to-end. The next scene shows that every CREATE INDEX you write adds a SECOND B-tree beside this one — and what that costs on every write.
All 11 scenes in Build a B-tree storage engine (SQLite-style) · Every curriculum