From d234ddf2902f7774d84798ef069d1973045ba140 Mon Sep 17 00:00:00 2001 From: Taewoon Kim Date: Tue, 3 Nov 2026 00:22:46 +0900 Subject: [PATCH] docs: searches keep answering during an explicit graph build from 26.11.1 The vectors how-to said searches wait while build_graph_now() runs and told readers not to call it while other threads search. ArcadeDB 26.11.1 (ArcadeData/arcadedb#11130) fixed that: searches answer from the graph in memory plus newer vectors and switch when the new graph is ready. Earlier engines and cold indexes (no graph in memory) still wait. Closes #197 Co-Authored-By: Claude Opus 5.5 --- docs/modules/ROOT/pages/how-to/vectors.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/modules/ROOT/pages/how-to/vectors.adoc b/docs/modules/ROOT/pages/how-to/vectors.adoc index 636051f..db9cc54 100644 --- a/docs/modules/ROOT/pages/how-to/vectors.adoc +++ b/docs/modules/ROOT/pages/how-to/vectors.adoc @@ -279,7 +279,7 @@ print(notes.get_stats()["searchOperations"] > before) True ---- -`build_graph_now()` rebuilds the graph at once and returns when the graph is built. Call it after a bulk load, so that no search waits for a lazy build. While it runs, searches on that index wait until it returns, and inserts carry on. Ctrl-C takes effect only when it returns, and a process killed during the build leaves a consistent database whose next build covers every vector. +`build_graph_now()` rebuilds the graph at once and returns when the graph is built. Call it after a bulk load, so that no search waits for a lazy build. From ArcadeDB 26.11.1, the engine these bindings ship, searches keep answering while it runs, from the graph in memory plus the vectors written since, and switch to the new graph when it is ready, as during the automatic background rebuild. Engines before 26.11.1 made every search on that index wait until the build returned. An index with no graph in memory yet, for example one not searched since the database was opened, still makes searches wait, because there is nothing else to answer from; `warm_up()` below loads it first. Inserts carry on. Ctrl-C takes effect only when it returns, and a process killed during the build leaves a consistent database whose next build covers every vector. The reads of a `VectorIndex` you hold (`get_size()`, `get_metadata()`, `get_quantization()`, `get_stats()`) ask the engine each time. After `DROP INDEX` they raise an error that names the index, and after the index is created again they report its new configuration. @@ -301,7 +301,7 @@ print(notes.get_size()) An agent that writes one record per turn and searches right after needs no setting: the rebuild runs in the background and the searches keep running while it does. -If the tail of the search latency matters more than the agent's total time, you can move the rebuild to a moment of your choosing: raise `mutations_before_rebuild` far above the number of writes, set the database setting `arcadedb.vectorIndex.maxDeltaScanRatio` to 0, and call `build_graph_now()` right before a step in which the agent does not search, such as its call to the language model. Do not call it while other threads search the same index, because they wait for it. +If the tail of the search latency matters more than the agent's total time, you can move the rebuild to a moment of your choosing: raise `mutations_before_rebuild` far above the number of writes, set the database setting `arcadedb.vectorIndex.maxDeltaScanRatio` to 0, and call `build_graph_now()` right before a step in which the agent does not search, such as its call to the language model. The table compares the two on {jvm-pkg-name} and {native-pkg-name} 26.11.1.dev0: 768-dimensional COSINE vectors, 10,000 records at the start, one insert and four k = 10 searches per turn at efSearch 100, `build_graph_now()` every 1,000 turns, two efficiency cores of a laptop, the first 3,000 turns. Each ratio is the median over paired runs of the same package; the two packages ran separately and are not compared with each other.