The access planner has code to avoid intersecting bounds of leaf expressions when the index is multikey. This prevents the access planner from inadvertently intersecting bounds for a self-intersection index plan on a multikey index.
if (boundsToFillOut->fields[pos].name.empty()) { // The bounds will be compounded. This is OK because the // plan enumerator told us that it is OK. return true; } else { if (MatchExpression::AND == mergeType) { // The bounds will be intersected. This is OK provided // that the index is NOT multikey. return !index.multikey; } else { // The bounds will be unionized. return true; } }
The changes from SERVER-22401 will make it possible to generate an assignment where it is possible to intersect bounds on fields where no prefix causes the index to be multikey. We should change the plan enumerator to convey to the access planner that it is possible to intersect bounds in some circumstances, even when the index is multikey. This will involve adding an additional member and plumbing it through OneIndexAssignment --> IndexTag --> PlanCacheIndexTree. The information needs to be stored in PlanCacheIndexTree so that we correctly decide when it is possible to intersect bounds for plans created from the plan cache.
- is depended on by
-
SERVER-22401 Implement index bounds generation rules for path-level multikey tracking in the PlanEnumerator
- Closed