[SERVER-46233] Aggregation $sort stages that get pushed down may miss opportunities to be optimized Created: 18/Feb/20  Updated: 29/Oct/23  Resolved: 24/Mar/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.4.0-rc0, 4.7.0

Type: Bug Priority: Major - P3
Reporter: Justin Seyster Assignee: Justin Seyster
Resolution: Fixed Votes: 0
Labels: qexec-team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.4
Sprint: Query 2020-02-24, Query 2020-03-09, Query 2020-03-23, Query 2020-04-06
Participants:
Linked BF Score: 15

 Description   

In some cases, ordering a $match in front of a $sort can require a second call to pipelineOptimize: the first call simplifies the $match, enabling the second call to recognize that the $match can be moved.

After SERVER-7568, it's possible for a sort to get pushed into the $cursor stage before the second call to pipelineOptimize, preventing the optimization from happening.



 Comments   
Comment by Githook User [ 06/Apr/20 ]

Author:

{'name': 'Justin Seyster', 'email': 'justin.seyster@mongodb.com', 'username': 'jseyster'}

Message: SERVER-46233 Relocate second call to optimizePipeline()

The second call to optimizePipeline() can sometimes catch
optimizations that were missed in the first call. The first call
simplifies filter expressions, opening up some optimization
opportunities that were previously blocked.

We want to catch these opportunities before we push down any stages
into the PlanExecutor.

(cherry picked from commit 30bd61a92cd4c8d6dd5588b59b9bdf4a0cd3c7d8)
Branch: v4.4
https://github.com/mongodb/mongo/commit/66c085520ffde8bf8fcf8440c7155e243cb00242

Comment by Githook User [ 24/Mar/20 ]

Author:

{'name': 'Justin Seyster', 'username': 'jseyster', 'email': 'justin.seyster@mongodb.com'}

Message: SERVER-46233 Relocate second call to optimizePipeline()

The second call to optimizePipeline() can sometimes catch
optimizations that were missed in the first call. The first call
simplifies filter expressions, opening up some optimization
opportunities that were previously blocked.

We want to catch these opportunities before we push down any stages
into the PlanExecutor.
Branch: master
https://github.com/mongodb/mongo/commit/30bd61a92cd4c8d6dd5588b59b9bdf4a0cd3c7d8

Generated at Thu Feb 08 05:10:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.