You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Milvus row id does not match with tantivy doc id, so we first get the tantivy doc id produced by query,
then we search the related doc id, which stores in the "doc_id" field with type fast_field.
This one by one process is not efficient: 1. dynamic dispatch is involed when getting doc id in "doc_id" field, 2. we cannot benefit from SIMD optimization. 3. memory locality and so on.
Why is this needed?
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered:
Milvus row id does not match with tantivy doc id, so we first get the tantivy doc id produced by query, then we search the related doc id, which stores in the "doc_id" field with type fast_field.
This one by one process is not efficient: 1. dynamic dispatch is involed when getting doc id in "doc_id" field, 2. we cannot benefit from SIMD optimization. 3. memory locality and so on.
Why is this needed?
No response
Anything else?
No response
is it a good idea to have a specialized map implementation for doc id to accelerate
Is there an existing issue for this?
What would you like to be added?
Milvus row id does not match with tantivy doc id, so we first get the tantivy doc id produced by query,
then we search the related doc id, which stores in the "doc_id" field with type fast_field.
This one by one process is not efficient: 1. dynamic dispatch is involed when getting doc id in "doc_id" field, 2. we cannot benefit from SIMD optimization. 3. memory locality and so on.
Why is this needed?
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: