-
Type:
New Feature
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Optimization
-
None
-
None
-
None
-
None
-
None
-
None
-
None
In SERVER-94738 (from HELP-64477) we saw that index pruning logic did not account for OR pushdowns, and would prune indexes that could potentially create stricter bounds using the pushed down predicates:
assert.commandWorked(coll.createIndex({a: 1, unused_field: 1})) assert.commandWorked(coll.createIndex({a: 1, b: 1})) coll.find({ $or: [{a: 1}, {a: {$exists: false}}], b: 2 }).explain() // with index pruning enabled, this query would not consider the {a: 1, b: 1} index
We should have index pruning either bail out in these cases, or account for the OR pushdown. Here is bailout logic that fixes this issue.
As part of this ticket, we should also expand testing of different AND/OR cases, to make sure we don't prune useful indexes in other scenarios. SERVER-92232 will also help in this scenario.
- depends on
-
SERVER-92232 Create property-based test to assert that pruned plans are not better than remaining plans
-
- Open
-
- is depended on by
-
SERVER-94155 Re-enable index pruning for distinct scan
-
- Blocked
-
- is related to
-
SERVER-94738 Disable index pruning during query planning
-
- Closed
-