What I do know is compact, similar to autovacuum in sqlite, can shrink the file and they seem to have a very different approach, although they all truncate the file from end.
For sqlite, db maintains the freelist of unused pages of the file. When transaction commits, sqlite will try to move valid pages from the end of file to free pages, then truncating the file. Of course, the parent's pointer to relocated pages needs to be updated. Sounds simple. (Some references:
But for compact in WiredTiger, it seems quite complex, connected with btree layer, block manager, and checkpoints.
I'm trying to ask some specific questions:
1. why does the action TRUNCATE (`__wt_block_extlist_truncate`) happen inside the checkpoint path( `__wt_block_checkpoint` -> `__ckpt_process`) instead of placed after the third checkpoint in `__compact_worker` ? After all, it is COMPACT not CHECKPOINT meant to truncate the file acoording to API semantics, right ?
( regular CHECKPOINT also truncate file ? )
2. Maybe the avail list in WiredTiger resembles the freelist pages in sqlite ?
sqlite chooses to shrink file at the commit of transaction whereas wiredtiger uses CHECKPOINT
to control the release of free blocks (maybe because the end blocks are referenced by older checkpoints
or named checkpoints, so they cann't be free)
3. What is the fundamental reason that wiredtiger makes compaction (vacuum in other db term)
dependent on CHECKPOINT ?