Repository navigation
[diskann-inmem] Move start points to the beginning - #1528
Mark Hildebrand (hildebrandmw) wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
Initialization leaves the freelist on frozen start-point slots in both representations, causing the first insertion to fail when at least 20 start points are present despite writable capacity.
1 open issue
What changed in this PR
This PR moves diskann-inmem start points to the beginning of the internal ID space, allowing serialized indexes to grow on reload without relocating start-point edges.
Changes:
- Updates full-precision and quantized representations and their tests for the new layout.
- Sizes ID translation tables using
IdLimitrather than writable capacity. - Removes public guarantees about start-point placement and wraps full-precision configuration errors in an opaque type.
| File | Description |
|---|---|
diskann-inmem/src/store/mod.rs |
Removes documentation assuming start points occupy trailing slots. |
diskann-inmem/src/repr/quantized/mod.rs |
Moves quantized start points to leading slots and adjusts tests. |
diskann-inmem/src/repr/mod.rs |
Explains serialization benefits and relaxes slot-layout guarantees. |
diskann-inmem/src/repr/full.rs |
Moves full-precision start points, updates tests, and changes configuration errors. |
diskann-inmem/src/provider.rs |
Uses the representation’s ID limit for mapping allocation and updates tests. |
diskann-inmem/src/ids.rs |
Updates mapping allocation, bounds checks, and tests to use IdLimit. |
Review effort: Balanced
Codecov Report❌ Patch coverage is
❌ Your patch status has failed because the patch coverage (83.33%) is below the target coverage (90.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #1528 +/- ##
==========================================
+ Coverage 91.02% 92.06% +1.03%
==========================================
Files 602 602
Lines 124081 124109 +28
==========================================
+ Hits 112948 114257 +1309
+ Misses 11133 9852 -1281
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
I don't quite understand why you need renumbering if the start point is u32::MAX. You can just store them at the beginning when serialized as metadata. |
|
The start point was not |
38ed609 to
1c6e44c
Compare

It has been pointed out that locating start points at the beginning of the internal ID space has some really nice properties. In particular, it means that a serialized index can be reloaded at a potentially larger size without needing to renumber any internal edges.
Since
diskann-inmemdecouples the external vs internal ID, making this change is relatively straight-forward outside of updating a few tests that relied pretty closely on this behavior. There are several categories of changes:full.rs/quantization/mod.rs: These mechanically move the start point range to the beginning of the ID space and update a few tests as mentioned above.: Id translation had a small optimization where it didn't allocate translation space for ids beyond theCapacity. With this change, the upper-bound is changed toIdLimit` and while this means we allocate a bit of unused space for translating start point ID slots, these translation slots are never populated so we still cannot accidentally return start points.This does technically break
Full::ConfigError's API, but this is likely not impactful.