Hi @lvca,
I’m thinking about the scenario where the threshold (e.g., 1,000 vectors) isn't reached. If a user adds 250 vectors and then stops, those 250 entries will stay in the brute-force RAM indefinitely. While brute forcing 250 vectors is fast, it's still less efficient than the JVector graph, and those vectors won't be persisted to the official index until the next big batch.
Would you consider adding a inactivity timeout for the rebuild trigger?
The logic would look something like this:
- Threshold Trigger: Rebuild immediately if mutations >= 1000.
- Time Trigger: If mutations > 0 but less than 1,000, start a timer (e.g., 10–30 seconds).
- Reset Logic: If a new vector is added during that window, reset the timer.
- Final Action: Once the timer expires with no new activity, trigger the async rebuild regardless of the count.
This would ensure the index stays fully optimized and persisted even during low-volume ingestion periods. WDYT?
Malek
Originally posted by @lekmaneb in #3679
Originally posted by @lekmaneb in #3679