[gedaiu]

Every vector search on a knowledge base with 3072-dim embeddings (text-embedding-3-large) scans the whole table. pgvector's HNSW holds vector up to 2000 dims, so vector_index never built an index for these, and the comment there said halfvec would wait until someone needs it. We need it: in our deployment chunks, entities.profile_embedding and name_vectors are all 3072 dims with no HNSW index. Name lookups run up to 35 s, reading name_vectors (3.5 GB) from disk, and the database sits at its CPU limit.

Above 2000 dims the build job now makes the same partial expression index on col::halfvec(N) with halfvec_cosine_ops (halfvec goes to 4000). The index only picks the candidates. Each search selects its distance with vector_index::distance, which stays col::vector(N), while ORDER BY uses the new vector_index::index_order, which matches the index expression. The outer RESORT that already exists then orders the candidates by full-precision distance. Half precision can therefore only affect which rows make the candidate list, never a score or the order returned. At 2000 dims or fewer index_order equals distance, so the SQL is unchanged there.

The three nearest-neighbour searches (documents::vector_search, name_vectors::nearest, entity-profile neighbours in resolution.rs) use index_order. name_vectors::nearest also now runs in a transaction with relaxed_order. It never set it, which was harmless without an index, but with one a small base sharing the table would come back short (rule 3).

a_wide_embedding_is_ranked_at_full_precision builds a 2001-dim index, checks it is a halfvec one, forces the planner onto it and confirms through idx_scan that the search used it. It places two chunks whose distances tie in half precision and differ in full precision, with the farther one holding the smaller id. Scoring the candidates with the half-precision expression puts that one first and fails the test. A small base beside the big one still fills its limit.

On a deployment that already holds 3072-dim rows, the next write of each kind queues its build. The builds are CONCURRENTLY and serial, so searches keep their current (slow) path until each index is valid.

🤖 Generated with Claude Code