feat(core): use compact chunk_size=64 for temporal_vec to reclaim ~512 MB - #1499
Merged
Conversation
Contributor
Codecov Results 📊✅ Patch coverage is 88.89%. Project has 6569 uncovered lines. Files with missing lines (1)
Coverage diff@@ Coverage Diff @@
## main #PR +/-##
==========================================
+ Coverage 76.02% 76.03% +0.01%
==========================================
Files 172 172 —
Lines 27398 27407 +9
Branches 19665 19670 +5
==========================================
+ Hits 20829 20838 +9
- Misses 6569 6569 —
- Partials 2000 1999 -1Generated by Codecov Action |
Contributor
|
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Reduces the temporal_vec0 chunk size from sqlite-vec’s default 1,024 vectors (~3 MB at 768 dims) to 64 vectors (~192 KB), saving ~512 MB on a 2.6 GB DB by avoiding tail-of-partition reserved empty slots.
Why
With the session coalescing PR (1495) the partition-tax floor fell from ~13.5 GB to 2.6 GB. The remaining 1.5 GB inside
temporal_vec_vector_chunks00is dominated by 1,024-slot chunks whose last chunk in each partition is mostly empty (~8–20%). The chunk_size=64 option is already supported by sqlite-vec@0.1.9 (verified via "CREATE VIRTUAL TABLE… chunk_size=8" upstream tests).Changes
vec0Ddl(): emitchunk_size=64fortemporal_veconly (default 1,024 stays forknowledge_vec/entity_vec/distillation_vecwhich are large, dense, and perform better with default chunks).kv_metakeyvec.temporal_chunk_sizerecords the active size;vec0Rebuildnow requires BOTHproject_onlyandTEMPORAL_CHUNK_SIZEto skip — this guarantees a 1,024-slot pre-existing project-only table is rebuilt exactly once.ensureVec0Storewrites the marker on first-time creation or dimension recreation; leaves an existing same-dimension table unmarked (per fix(core): preserve temporal KNN partition pushdown before vacuum #1496 invariant).vec0-cutover.test.tsadds (a) "temporal vec0 records the compact chunk size at fresh install" and (b) "KNN top-k ordering is identical between 64-slot and 1024-slot chunks on the same vector set" — locks in the no-search-quality-regression invariant. Plus the existing vec0-rebuild test suite continues to pass.Measured impact
The remaining ~1 GB is the actual floor: 311,696 vectors × 768 dims × 4 bytes.
Why not 12x anymore
Earlier estimate of 12x reduction was misleading: with one project partition left after PR #1494, the only "waste" was the partial last chunk. Discovered by reading
dbstatpage sizes after vacuuming.Verification