[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: |
|
||||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Sprint: | Query 2020-08-24 | ||||
| Participants: | |||||
| Case: | (copied to CRM) | ||||
| 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: |
| Comment by Louis Williams [ 27/Apr/20 ] |
|
I have a patch for this server-25782 |