Two asks, both about making eviction possible. Measured from AgentCode, which is the consumer that needs them.
Why
AgentCode indexes a repository into immutable generations. On a 0.57 MB Rust source tree (18 files), durable state grows by about 16.5 MB per generation regardless of how small the edit was, and nothing ever removes it:
| generation |
durable state |
multiple of source |
| 1 |
38.9 MB |
65.7x |
| 6 |
126.8 MB |
213.9x |
Extrapolated, 100 generations of a 0.57 MB tree is roughly 1.7 GB. A 5 MB tree at the same ratio is roughly 15 GB, and a day of editing is far more than 100 generations.
Most of that is AgentCode's own problem to fix (our facts are generation-scoped, so one changed file invalidates every posting mentioning any term in it). But we cannot build eviction at all without two things from WorkTable.
Ask 1: delete_many, the mirror of insert_many
There is no bulk delete today. Evicting one generation means removing about 14,400 rows per table, and at the current per-row cost that is as slow as writing them was, so eviction would cost roughly what indexing cost.
Same contract as insert_many, which works well: all-or-nothing, and a row_index on the rejected row so the caller can find it in a batch of 14,400.
Ask 2: confirm vacuum returns pages to the free list on the eviction path
reclaim_pages marks pages reusable, which is exactly what eviction needs: the next generation should reuse the space rather than extend the file. What is not clear from the outside is whether a Vacuum run after a bulk delete guarantees that.
If it already does, say so and we will build against it. If it does not, that is the gap.
Not asked for: shrinking the file back to the OS. Reuse is enough.
Context
Measurements are recorded in AgentCode at docs/benchmarks/state-growth.md. Related: the RandomMultiPair quadratic-insert regression, pathscale/WorkTablesIndex#13.
Two asks, both about making eviction possible. Measured from AgentCode, which is the consumer that needs them.
Why
AgentCode indexes a repository into immutable generations. On a 0.57 MB Rust source tree (18 files), durable state grows by about 16.5 MB per generation regardless of how small the edit was, and nothing ever removes it:
Extrapolated, 100 generations of a 0.57 MB tree is roughly 1.7 GB. A 5 MB tree at the same ratio is roughly 15 GB, and a day of editing is far more than 100 generations.
Most of that is AgentCode's own problem to fix (our facts are generation-scoped, so one changed file invalidates every posting mentioning any term in it). But we cannot build eviction at all without two things from WorkTable.
Ask 1:
delete_many, the mirror ofinsert_manyThere is no bulk delete today. Evicting one generation means removing about 14,400 rows per table, and at the current per-row cost that is as slow as writing them was, so eviction would cost roughly what indexing cost.
Same contract as
insert_many, which works well: all-or-nothing, and arow_indexon the rejected row so the caller can find it in a batch of 14,400.Ask 2: confirm vacuum returns pages to the free list on the eviction path
reclaim_pagesmarks pages reusable, which is exactly what eviction needs: the next generation should reuse the space rather than extend the file. What is not clear from the outside is whether aVacuumrun after a bulk delete guarantees that.If it already does, say so and we will build against it. If it does not, that is the gap.
Not asked for: shrinking the file back to the OS. Reuse is enough.
Context
Measurements are recorded in AgentCode at
docs/benchmarks/state-growth.md. Related: theRandomMultiPairquadratic-insert regression, pathscale/WorkTablesIndex#13.