-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Integration
In the previous tickets SERVER-96059, SERVER-96064, & SERVER-96065, optimizations were introduced in various cases that removed a redundant $sort stage. However, these optimizations only worked if the $sort stage came directly after the stage that sorted the documents.
All these optimizations should be generalizable in the same way: if any number of stages are added between the sorting stage and the $sort that do not impact the sort order, the $sort should still be removable.
Look at SERVER-96067 to understand how to determine if a stage in general is know to preserve sort order or not, within the optimization logic.
Test coverage should be added to all these cases that adding stages that preserve sort order do not impact the ability to remove the $sort, and also that the opposite is true.
- depends on
-
SERVER-96059 Optimize away metadata $sort directly after $search for single node environments
- Open
-
SERVER-96065 Optimize away $sort directly after sorted $mergeCursors for sharded environments
- Open
-
SERVER-96067 Properly set the ‘preserveOrderAndMetadata’ field for common aggregation states
- Open
-
SERVER-96064 Optimize away $sort directly after $vectorSearch for single node environments
- Closed
- is related to
-
SERVER-94628 Ensure we do not do a redundant $sort by search score during $rankFusion.
- Closed