Repro:
> t = db.t
> t.drop()
> t.ensureIndex({a: 1})
> t.ensureIndex({b: 1})
> t.ensureIndex({a: 1, b: 1})
> t.find({a: 1, b: 1})
Using the compound index is always better than index intersection for the query above. However, we generate index intersection solutions, e.g.:
FETCH
---fetched = 1
---sortedByDiskLoc = 0
---getSort = []
---Child:
------KEEP_MUTATIONS
---------filter:
$and
a == 1.0
b == 1.0
---------fetched = 0
---------sortedByDiskLoc = 0
---------getSort = []
---------Child:
------------AND_HASH
---------------fetched = 0
---------------sortedByDiskLoc = 0
---------------getSort = [{ a: 1 }, { a: 1, b: 1 }, { b: 1 }, ]
---------------Child 0:
---------------IXSCAN
------------------keyPattern = { b: 1.0 }
------------------direction = 1
------------------bounds = field #0['b']: [1.0, 1.0]
------------------fetched = 0
------------------fetched = 0
------------------sortedByDiskLoc = 1
------------------getSort = [{ b: 1 }, ]
---------------Child 1:
---------------IXSCAN
------------------keyPattern = { a: 1.0, b: 1.0 }
------------------direction = 1
------------------bounds = field #0['a']: [1.0, 1.0], field #1['b']: [MinKey, MaxKey]
------------------fetched = 0
------------------fetched = 0
------------------sortedByDiskLoc = 0
------------------getSort = [{ a: 1 }, { a: 1, b: 1 }, { b: 1 }, ]
We perhaps shouldn't even generate index intersection solutions that we know will perform worse than the compound index solution.
- is related to
-
SERVER-12673 index bounds incorrect on compound index with simple query
-
- Closed
-