Count page references and compact from the victim segment

[venkat1701]

Stacked on #80. Phase 3 of the page directory work: the engine counts references to every page as it commits, and compaction no longer walks the trees.

Why

After #80 compaction moved pages instead of rewriting trees, but it still found the live pages by walking every retained tree. At scale 4 that walk allocated about 1 GB, and its cost grew with the size of the database rather than with what was being cleaned. It also meant background compaction only ran every 256 MB of writing, and bulk loads that overlapped a compaction had to retry.

What changes

• Reference counts. data/segments/pages.ref holds one count per page number: how many branch roots, branch nodes and leaf values point at it. A background thread (hstore-references) updates the counts after each published commit by comparing the roots before and after. The commit path only puts the pair of generations on a queue. A node that a commit copies cancels out against its old version, so only the pages a commit really added or dropped get written.
• Dead pages wait for readers. A page whose count reaches zero is marked with the generation it died in. A checkpoint releases it once no retained generation or open reader is older than that, which clears its directory entry and takes its bytes off its segment's live total. Readers now check after pinning that their generation is still retained, and trimming puts a generation back if it races with a pin, so a reader can't hold a generation whose pages were released.
• Crash safety. pages.ref only changes at checkpoints. Changed counts and released entries go to pages.ref.journal first, the catalog is published, and then the journal is applied, so after a crash the counts match one checkpoint or the next. On open the journal is applied if it belongs to the published checkpoint, the counts are brought forward over the generations replayed from the WAL, and a scan of the directory releases pages that no committed generation refers to (pages a crash cut off from their transaction). If counting ever fails, the file is marked and the next open rebuilds the counts from the retained generations.
• Leaf flag. A leaf sets a header bit when any of its values points at another page, and decoding checks it. The counter reads only the header of an uncached leaf without the bit, which keeps counting the replayed commits after a crash about as cheap as replaying them.
• Compaction reads the victim, not the trees. Victims are picked from the per-segment live counts. PageStore.evacuate reads through the victim and copies every page whose directory entry still points at that spot, repointing the entries every 4 MiB after a sync as before. A segment is only picked once every page allocated in it has been written. Work is proportional to the victim.
• No more bulk-load fence. Pages a load spills before commit have directory entries, so evacuation moves them like any other page, and a transaction that loaded data before a compaction now commits. Pages spilled by a transaction that aborts, conflicts or repeats an earlier request are marked dead straight away.
• Maintenance. Background compaction runs whenever a segment is below compaction_live_ratio, one segment per pass. Checkpoints also run after checkpoint_wal_mb of page writes and when a million counts have changed, so dead pages are released during bulk loads and the in-memory change map stays small. A checkpoint now syncs the segments before it takes the commit lock and applies the journal after letting it go.
• hstore check compares the counts with a full walk, and liveness() returns the live counters instead of walking (the Studio segment view called it once per segment).
• A separate commit fixes recovery of a branch created after the last checkpoint: redo applied its roots before the branch existed, and the next open failed with a NullPointerException. That bug is on main too.
• Storage format goes to 5.

Testing

• Full suite: 129 tests pass, and each commit builds and passes on its own.
• New ReferenceCountTest runs random work over three seeds (inserts and removals, edge deletes, bulk loads, aborted loads, branches written to and sometimes dropped) and checks every count against a full walk after checkpoints and after reopening. It also covers pages a pinned reader can still reach waiting until it closes, aborted, replaced and duplicate loads giving their pages back, pages spilled by a transaction cut short by a crash being released on open, the counts surviving a crash with and without a half-applied checkpoint (new crash point CHECKPOINT_JOURNAL), and counts marked for rebuild being rebuilt.
• Compaction and crash tests now check the counts after recovery too. The bulk-load test now commits instead of retrying, and fails if evacuation skips pages that aren't counted yet.
• I broke the counter on purpose in eight ways (dropping a decrement, ignoring readers when releasing, skipping the journal on open, not counting replayed commits, leaking spilled pages, and so on). Each one fails at least one test.
• Native image: loaded examples/clinical-claims.hql and hstore check reports 105 pages in use, 423 waiting for older readers with the counts matching a full walk. SIGKILL partway through a 20,000-insert load, reopen replayed 1,395 commits and the counts matched. One more write trimmed the history, COMPACT; emptied and deleted the old segment, and check passed again.

Timing

On a fresh Azure D8ds_v5 (8 vCPU, 32 GiB, local SSD). The same compaction probe as #80: load scale 4, delete 20% of the edges and remove 20,000 members, reopen, then run a full compact() while a second thread commits single updates. Node cache 64 MiB, two runs each:

	#80, 4 GiB	this branch, 4 GiB	#80, 1 GiB	this branch, 1 GiB
disk after load and churn, before compaction	1.4 to 1.5 GB	0.84 to 0.98 GB	1.5 to 1.6 GB	0.83 to 0.96 GB
full compaction	1.2 s	0.5 to 1.1 s	1.2 to 1.5 s	0.6 to 1.2 s
allocated on the compacting thread	1.0 GB	107 to 194 MB	0.9 to 1.1 GB	107 to 208 MB
disk after compaction	295 to 368 MB	261 to 372 MB	297 to 405 MB	246 to 376 MB
longest commit during compaction	21 to 22 ms	21 to 46 ms	23 to 32 ms	24 to 55 ms

Disk stays lower during the load because background compaction now runs whenever a segment is mostly dead, instead of every 256 MB of writes. The counter thread used about 7 s of CPU and allocated about 3 GB over the whole load and churn (roughly 600 large commits), and about 0.15 s and 2 MB during the 2,000 to 3,500 small commits of the compaction phase.

The HStore benchmark, #80 against this branch, default cache, throughput ratio (medians of 3 runs at scale 1 and 2 at scale 4). Runs of the same setup varied by up to 10 to 20% on many rows:

Workload	scale 1	scale 4
ingest.nodes	0.97	1.01
ingest.edges	0.98	1.00
read.incidence	1.07	0.89
read.members	0.96	0.98
read.twohop	1.01	1.00
latency.read	0.94	0.94
write.update	1.02	1.02
latency.commit	0.95	0.90
mixed.read	0.92	0.82
churn.delete	0.89	0.96
churn.remove	0.97	0.89
recover	0.61	0.66
disk after load	197 MB vs 189	330 MB vs 1,039 to 1,072

The costs, plainly:

• mixed.read, readers running alongside a writer, is 8 to 18% lower. The counter and the more frequent background compaction compete with the readers for CPU. This is the main thing I'd like to bring down next.
• recover (opening after a SIGKILL halfway through loading) takes about 55 ms instead of 34 at scale 1 and about 330 ms instead of 200 at scale 4, for counting the replayed commits and scanning the directory. Before the leaf flag it was ten times slower than Compact by moving pages instead of rewriting trees #80.
• latency.commit is 5 to 10% lower, inside the spread at scale 4.
• Disk at scale 1 is 8 MB bigger: the first chunk of pages.ref.