[SERVER-15958] The "isMultiKey" value is not correct in the output of aggregation explain plan Created: 04/Nov/14 Updated: 11/Jul/16 Resolved: 12/Nov/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework, Diagnostics, Querying |
| Affects Version/s: | 2.6.5 |
| Fix Version/s: | 2.6.6, 2.8.0-rc1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Linda Qin | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backport Completed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
The $match aggregation pipeline uses a multikey index, however, "isMultiKey" is false in the output of aggregation explain plan. Also, the index being used ("y_1") is missing in the field ("cursor" : "BtreeCursor "). It would be nice if the output can be ("cursor" : "BtreeCursor y_1"). |
| Comments |
| Comment by Githook User [ 20/Nov/14 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: (cherry picked from commit 52db1600fcde4a5b6bd25ed83802d02bde64538c) Conflicts: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 12/Nov/14 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by J Rassi [ 05/Nov/14 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
linda.qin@10gen.com: the "cursor" reporting error is being tracked by It looks like the "isMultiKey" issue is caused by the fact that the explain machinery is expecting that the given plan has been executed, but the aggregation framework does not execute the given plan before invoking the explain machinery (and, by contrast, the find().explain() path does execute the plan before explaining it). The IndexScanStats::isMultiKey flag only is set on the first call made to IndexScan::work(), so if no call to PlanExecutor::getNext() is made, then this field gets the default value of false. Possible ways to fix this issue in 2.6.x aggregation:
This issue has a somewhat wider impact in 2.7.x, as it more broadly affects all uses of the "queryPlanner" explain verbosity (which aggregation uses). My index stats patch (which isn't going in) actually moved initialization of isMultiKey to the IndexScan constructor, so maybe that's the entire fix? As for 2.6.x, I haven't investigated whether it's safe there to access the catalog from the IndexScan constructor, but I can't think of any reasons why not right now. See the following repro:
Assigning to david.storch. |