[SERVER-17148] Remove plans do not need a FETCH stage Created: 02/Feb/15 Updated: 30/Jan/24 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | David Storch | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 5 |
| Labels: | query-director-triage | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||||||||||||||
| Sprint: | Quint 9 09/18/15 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||
| Description |
|
Currently, indexed .remove() plans will always fetch the documents associated with the index keys before performing the remove:
As an optimization, we could change the query planner to generate indexed .remove() plans without the FETCH stage. |
| Comments |
| Comment by Asya Kamsky [ 18/Sep/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Note that many count commands now don't use a FETCH as result of | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by David Storch [ 07/Feb/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Note that this also applies to IDHACK remove and IDHACK count plans, which are used when the remove/count predicate is a simple lookup on _id. Such plans won't have an explicit FETCH stage, since the IDHACK stage fetches the entire document itself. However, we can still optimize such plans by refraining from fetching the document during IDHACK. One can see that the IDHACK stage involves a document fetch in the explain output:
In particular, the IDHACK stage in the executionStats section reports a docsExamined value of 1. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by zhyk [ 10/Jun/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
SERVER-17266 is actually another problem, it is more like COUNT_SCAN vs. IXSCAN problem (after doing explain on my machine). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by zhyk [ 10/Jun/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
So that COUNT may depend on FETCH? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 10/Jun/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Looks like SERVER-17266 is the count issue. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 10/Jun/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I believe that's expected when COUNT_SCAN cannot be used. If that's something we want to fix it should probably be a different ticket. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by zhyk [ 10/Jun/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Count FETCHs when COUNT_SCAN not work, and forced IXSCAN.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 18/May/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Count does not seem to ever FETCH so I think this ticket is just for remove now. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by J Rassi [ 12/Feb/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Count plans, too. |