Index bloat and B-tree page merge, part 2

session summary

The session established why sparse B-tree pages matter: they increase buffer churn, WAL full-page images, replica storage, and the cost of scans. The group then traced vacuum's existing half-dead page deletion and studied whether a merge could resemble a split. Moving tuples directly exposed a duplicate-read race for concurrent scans, implying a two-phase protocol that removes the parent downlink before relocation. By the end they identified split/finish-split as the code to reverse, but deferred implementation pending a sound scan protocol.

timecodes

1. 01:30 Operational costs of sparse B-tree pages
2. 10:00 Why Postgres has reindexing but no page merge
3. 15:00 Can merge be shaped like an existing page split?
4. 20:00 Tracing vacuum and half-dead page deletion
5. 35:00 Moving tuples into a sibling before deletion
6. 47:30 Concurrent scans expose duplicate reads
7. 55:00 A two-phase merge and scan-awareness requirement
8. 01:08:30 Reversing finish-split becomes the next design step