LSM_VECTOR PRODUCT: a reopen with nothing deleted logs "Deleted vectors detected" and skips the #8852 ordinal-map path, so the first search re-reads every vector's document #10568

After #8852 (fixed in #8863), a reopened LSM_VECTOR index with quantization NONE loads its graph through the ordinal map recorded next to it and skips the per-vector document read. A PRODUCT-quantized index with nothing deleted still takes the old walk on every reopen, and it also logs a line that says vectors were deleted.

What happens

On reopen with getDeletedCount() == 0, loadPersistedGraphOrDecidePrefix calls reusePersistedGraphDespiteDeletions(gf, true) (the #8852 path). That method returns null at once for PRODUCT and, before it does, logs:

Deleted vectors detected in index %s, which uses PRODUCT quantization: its PQ codes are addressed by the same ordinals the rebuild reassigns, so the graph is rebuilt from scratch rather than reused (issue #7842)

Nothing was deleted, and nothing is rebuilt either: the caller falls through to gf.loadGraph() plus the walk that re-reads every vector's document (the cost #8852 describes: 2.8 s at 1M vectors, 17.9 s at 10M). So the log line is false, and the first search after every reopen pays the O(N) read that #8852 removed for NONE.

The cause is the PRODUCT refusal that #7842 / #7844 added for the deletion case, which is right there: after a deletion the ordinal space has a hole and the PQ codes were built over a dense one. With no deletion the recorded map is exactly the array the PQ codes were built with. The refusal sits above both calls, so it also applies to the no-deletion call, and the writer does not record a map for PRODUCT at all (writeGraphManifest: "a file nothing will ever read", from the #7844 review), which #8852 later made untrue for the no-deletion case.

Measured

Untimed (laptop, not a controlled benchmark), Python bindings on engine 7f65a6e (upstream main of 2026-10-22), SIFT 100k, EUCLIDEAN, pqSubspaces 32, pqClusters 256, build_graph_now(), close, then open in a fresh process and run one vectorNeighbors (k 10, efSearch 100):

An idle check of 25 s after that first search showed no further CPU (0.13 s PRODUCT, 0.10 s NONE) and no changed index file, so no rebuild actually happens; the extra 0.19 s is most likely the walk (inferred from the difference, not profiled). I will add a 1M measurement to the fix PR.

Proposed fix

• record the ordinal map for PRODUCT too;
• let the exact-cover (no deletion) call reuse it for PRODUCT, when the PQ codes are loaded and are one per mapped ordinal;
• keep the PRODUCT refusal, and its log line, only for the call that runs because something was deleted;
• an index persisted by an older build has no map for PRODUCT: it keeps taking the walk, without the false line.

I will send the PR for this.

Two smaller things in the same area

Not part of the fix above, seen in my hunt on the same engine commit through SQL (not re-measured for this issue):

• the vectorNeighbors query option rerank is read with opts.getInt("rerank", -1) (SQLFunctionVectorNeighbors), so rerank: 2.5 is accepted, while index METADATA refuses rerankOversample 2.5;
• vectorNeighbors(..., -1, ...) returns 0 rows without an error.