[SERVER-25782] Allow SORT_MERGE plans even if some children are FETCH stages rather than IXSCAN stages Created: 24/Aug/16  Updated: 07/Feb/22  Resolved: 10/Aug/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.7.0

Type: Improvement Priority: Major - P3
Reporter: Chris Harris Assignee: Mindaugas Malinauskas
Resolution: Done Votes: 1
Labels: neweng, storch
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File explain.txt     HTML File server-25782    
Issue Links:
Related
Backwards Compatibility: Fully Compatible
Sprint: Query 2020-08-24
Participants:
Case:

 Description   

Currently the planner only considers an OR plan eligible for explodeForSort() if its children are all IXSCANs. In theory a FETCH shouldn’t prevent a SORT_MERGE plan from being eligible.

The attached explain from 3.2.4 seems to demonstrate the problem. Rather than leveraging the index to create a SORT_MERGE plan, a SORT plan is generated as a result of the FETCH required to satisfy the {$exists:false} filter.



 Comments   
Comment by Githook User [ 10/Aug/20 ]

Author:

{'name': 'Mindaugas Malinauskas', 'email': 'mindaugas.malinauskas@mongodb.com'}

Message: SERVER-25782 Allow SORT_MERGE plans even if some children are FETCH stages rather than IXSCAN stages
Branch: master
https://github.com/mongodb/mongo/commit/29f94f2e7695b46437e313e264e83e50b3f7b9c1

Comment by Louis Williams [ 27/Apr/20 ]

I have a patch for this server-25782 that I never extensively verified.

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