mirror of
https://github.com/qdrant/qdrant.git
synced 2026-09-29 09:27:53 -05:00
ae0b075c74
* perf: skip retrieval in scroll when no payload or vectors are requested Every scroll variant went through SegmentsSearcher::retrieve to build its records, even when neither payload nor vectors were asked for. That is a has_point lookup per id per segment plus a version and id resolution per hit, only to yield records holding nothing but the id. The universal query API always scrolls this way and fetches payload separately afterwards. Build the bare records from the ids directly in that case. The retrieve could only have dropped ids deleted in between, which the update lock held across the scroll rules out. * perf: fetch payload and vectors in the leaf of plain query requests A query without prefetches and without rescoring is served by a single leaf search or scroll whose result is returned as is. The planner still built that leaf without payload or vectors and filled them in afterwards through SegmentsSearcher::retrieve, which resolves every result id in every segment again: the same cost #10312 removed from the search API, paid once more at the end of each query. Let the leaf carry the requested payload and vectors instead, so the segment attaches them to the results it already holds by offset, and clear the root plan so the fill step is skipped. Prefetch leaves and rescored roots (MMR) are unchanged. As with the search API, this fetches payload for each segment's candidates rather than for the merged top `limit` alone. * Use new_empty function * fix: fetch payload and vectors in scroll leaves only (#10384) A search leaf hydrates every segment's local top-k before merging, so `with_payload` there multiplies payload I/O by the segment count — the regression #6279 fixed and `test_payload_io_read_is_within_limit[query]` guards. Scroll leaves retrieve once for the merged page, so they keep fetching directly; search leaves stay bare and the root plan retrieves for the final result. Claude-Session: https://claude.ai/code/session_01SUWh5PqUeSefrUqUwXxU3E Co-authored-by: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Andrey Vasnetsov <andrey@vasnetsov.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Collection
Crate, which implements all functions required for operations with a single collection of points. Points within a collection should share the same payload schema and have same vector size. So that search requests could be performed over all points of a single collection.
Structure
Update process
