Reviewing files that changed from the base of the PR and between 00e2436 and b07e264.

• lib/collection/src/operations/universal_query/planned_query.rs (18 hunks)
• lib/collection/src/shards/local_shard/formula_rescore.rs (1 hunks)
• lib/collection/src/shards/local_shard/query.rs (10 hunks)
• lib/segment/src/data_types/query_context.rs (1 hunks)
• lib/segment/src/segment/entry.rs (1 hunks)

• GitHub Check: test-snapshot-operations-s3-minio
• GitHub Check: test-shard-snapshot-api-s3-minio
• GitHub Check: test-low-resources
• GitHub Check: Basic TLS/HTTPS tests
• GitHub Check: test-consensus
• GitHub Check: test (macos-latest)
• GitHub Check: test-consensus-compose
• GitHub Check: test (windows-latest)
• GitHub Check: test (ubuntu-latest)

lib/segment/src/segment/entry.rs (1)

100-100: Confirm the forced disable of payload and vector retrieval
By calling self.process_search_result(..., &false.into(), &false.into(), hw_counter), the code effectively disables both payload and vector fetching. This is likely intentional to avoid unnecessary data retrieval during the rescore step. However, please verify there are no downstream consumers that rely on payload or vector data in this scenario.

lib/collection/src/shards/local_shard/formula_rescore.rs (1)

7-7: Minor import addition
The import of ScoredPoint appears aligned with the function’s return type and usage. No issues detected.

lib/segment/src/data_types/query_context.rs (1)

13-14: Removal of WithPayload and WithVector from imports
Eliminating WithPayload and WithVector from these imports is consistent with removing those fields from FormulaContext. This simplification avoids unused imports.

lib/collection/src/operations/universal_query/planned_query.rs (15)

21-21: New field for root plans
Introducing pub root_plans: Vec<RootPlan> clarifies how merges and final retrieval parameters (vectors/payload) are handled at the root level of each query. This aligns well with the PR’s restructuring.

---

71-76: Introduction of RootPlan struct
Defining RootPlan with merge_plan, with_vector, and with_payload centralizes key query configuration in one place. This design appears maintainable and consistent with the shift away from passing these parameters everywhere.

---

119-126: Construct MergePlan followed by RootPlan
Here, rescore_params is set to None within MergePlan, then wrapped in a new RootPlan. This flow supports passing the final retrieval flags (with_vector, with_payload) separately from any scoring logic.

---

140-150: MergePlan with RescoreParams
When the scoring query needs intermediate results, Some(RescoreParams) is created, and then wrapped in RootPlan. The approach neatly partitions the scoring logic from data retrieval details.

---

164-166: Explicitly disabling vector/payload in the initial search
Using with_vector: Some(false.into()) and with_payload: Some(false.into()) offloads retrieval until after the partial results are combined. This prevents redundant data loading, matching the PR’s performance goals.

---

187-188: OrderBy scroll request with no immediate fetch
Similarly, with_vector: false.into() and with_payload: false.into() ensure that large data is not needlessly fetched.

---

223-224: Random scroll request with no immediate fetch
Again, disabling payload and vector here avoids unnecessary overhead until final results are determined.

---

262-264: Defaulting prefetch payload/vector to false
Establishing with_payload and with_vector as false within prefetches is consistent with deferring retrieval until post-merge or final scoring steps.

---

283-284: Recursion into nested prefetches
Invoking recurse_prefetches here continues the prefetch logic. The updated function signature nicely ensures all nested sources follow the same approach for deferring payload/vector retrieval.

---

494-529: Unit test verifying multiple vector scoring layers
This test ensures that nested merges and final retrieval flags (with_vector/with_payload) are handled properly. The adjusted assertions confirm that final queries use the new RootPlan model.

---

658-658: Disable immediate vector retrieval in test
Applying with_vector: Some(WithVector::Bool(false)) aligns with the new pattern of delaying vector data retrieval to later steps.

---

671-672: Disable immediate vector retrieval in the second core search
Same reasoning as above: skipping vector retrieval at this stage can improve performance by deferring large data loading.

---

989-995: First RootPlan in mass test
The creation of RootPlan references an initial search index. No rescore parameters are applied. Well-structured for a simpler top-level query scenario.

---

997-1005: Second RootPlan in mass test
Same pattern: building a root plan with no rescore. Helps confirm that multiple queries can coexist without retrieving vector/payload prematurely.

---

1006-1023: Third RootPlan with nested Prefetch
Demonstrates a more complex scenario that includes an internal MergePlan plus final assembly without immediate retrieval. Good coverage of multi-layer merges.

lib/collection/src/shards/local_shard/query.rs (10)

12-12: Use of new types for payload and vector handling looks proper.
No issues found. This import line cleanly aligns with the refactoring approach described in the summary.

---

121-121: Flattening nested structures is appropriate.
Flattening the results is correct given ShardQueryResponse is a Vec<Vec<ScoredPoint>>. No issues found with this approach.

---

141-154: Re-collecting and enforcing record consistency looks good.
The logic properly filters out points that no longer exist or have been deleted. This maintains data integrity during retrieval. Implementation details appear sound.

---

161-199: Consolidated plan resolution structure is clear and maintainable.
Introducing resolve_plan provides a concise, centralized approach to merge prefetch results and fill payloads/vectors. This design improves readability and ensures consistent handling of plan logic.

---

289-289: Method signature update for fusion rescore is consistent.
The updated call to fusion_rescore() reflects the new scoring approach. No issues detected.

---

301-302: Using default false for payload/vector is aligned with refactoring.
Hardcoding with_payload and with_vector to false here matches the design goal of deferring payload/vector fetching until final resolution.

---

329-330: Switching to None for payload and vector selection is consistent.
This change matches the newly introduced optional approach, ensuring these fields are no longer forced on every search request.

---

353-354: Invoking formula-based rescoring appears valid.
Calls to self.rescore_with_formula now align with the revised parameters. Confirm that the new formula-based approach is tested for all relevant use cases.

---

412-412: No substantial changes in logic.
This line simply returns the fused data. No issues to report.

---

108-113:

✅ Verification successful

Validate external calls to updated function signature.
The parameter and return type have changed from a Vec<ScoredPoint> to ShardQueryResponse, which is expected given the restructured design. Ensure that all callers handle the updated type without breaking any downstream logic.

---

🏁 Script executed:

#!/bin/bash
# Verify that all calls to fill_with_payload_or_vectors have been updated accordingly
rg -A 3 "fill_with_payload_or_vectors"

Length of output: 678

---

Verified Update: Function Signature Change Confirmed

The updates in lib/collection/src/shards/local_shard/query.rs reflect the new signature for fill_with_payload_or_vectors correctly. The function now accepts a ShardQueryResponse rather than a Vec<ScoredPoint>, and the call site within the same file passes parameters consistently with this change. No additional caller appears out of sync.

Please ensure that all downstream logic that consumes the return value of this function properly handles the new ShardQueryResponse type.