Repository navigation
Disk space isn't reclaimed after deletes #47
Description
After churn.delete removes 20% of the hyperedges and churn.remove takes a member out of 20,000 more, HStore's files grow from 173 MiB to 406 MiB. JE's shrink from 272 MiB to 233 MiB on the same data (scale 1, async, default history of 64).
Likely suspects, none confirmed yet:
- the 64 retained generations still pin the old pages
- background compaction only starts after
checkpoint_wal_mb(256 MiB) of page writes and moves one segment per pass - WAL segments aren't trimmed before close
Run the churn with HISTORY=1 to see which one it is.
Activity
venkat1701 commentedon Oct 5, 2026
Found the main cause. History isn't it: with
history_limit1 the result is the same (415 against 416 MiB after churn). It's three things:With 16 MiB segments and one full compaction, disk went from 421 to 79 MiB for 23 MiB written.
compaction_live_ratiomade no difference between 0.3 and 0.9. Doing this more often needs #50 first, otherwise every pass stalls commits for seconds.venkat1701 commentedon Oct 11, 2026
Still true on main after #79 to #81, measured at scale 1 with defaults: 206 MB after load, 450 MB after the churn, 211 MB after a full compaction. Compaction itself now works and is cheap. Background compaction now starts from live bytes (#53 is closed), but at this size the data still sits in one or two 256 MiB segments and the active one is never a victim, so this now mostly waits on #52.