[SERVER-21064] It's possible to fail on sort memory overflow even if there is an alternative plan that requires no sort. Created: 22/Oct/15 Updated: 23/Oct/15 Resolved: 23/Oct/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 3.0.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Dmitry Ryabtsev | Assignee: | David Storch |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Sprint: | QuInt B (11/02/15) | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
With a collection that has two indexes like: If you run a query like: {a: { "$in": [1]}, b:1, c: { "$in": [1,2,3]}}).sort({c:1}), a query shape will be cached with the associated plans that do no require sort and it is likely that the plan using the a_1_b_1_c_1 will get the top score. If you now run query like: {a: { "$in": [1,2,3]}, b:1, c: { "$in": [1,2,3]}}).sort({c:1}), the cached plan with top score will be used. As the query requires SORT stage, the plan will be re-adjusted, however if at the sort stage we hit the 32Mb limit, the query will fail despite the fact that there is an alternative plan cached that uses the c_1_b_1_a_1 index, which if used, will require no sort and re-adjustment. |
| Comments |
| Comment by David Storch [ 23/Oct/15 ] | ||
|
After reproducing the issue, I can confirm that this is a duplicate of Prior to This ticket describes a scenario in which the cached plan backup plan strategy did not work. Suppose you have index {a: 1, b: 1, c: 1}. Consider plans which answer the following two predicates by scanning this index:
The former scan will be sorted by {c: 1} since it will return documents where c is 1, followed by docs where c is 2, followed by docs where c is 3. On the other hand, the latter scan will not be sorted by {c: 1}. However, as reported in
This is fixed by | ||
| Comment by David Storch [ 22/Oct/15 ] | ||
|
dmitry.ryabtsev, do have a repro script you could share? I tried to write a script based on your description but wasn't able to reproduce. Your repro would help me confirm that this issue was fixed by | ||
| Comment by Dmitry Ryabtsev [ 22/Oct/15 ] | ||
|
On 3.0.7 I'm able to reproduce this only after "db.runCommand({setParameter: 1, internalQueryCacheReplanningEnabled: false})". My understanding is that we re-adjust the cached plan having the top score by adding sort stage. Then we score it and compare the score against the second plan we have which has the optimal index. I'm concerned that this is a workaround but not the fix, as the winning plan can be the plan with sort. |