Details
-
Improvement
-
Resolution: Unresolved
-
Minor - P4
-
None
-
2.5.5
-
Query Optimization
-
Fully Compatible
Description
This ticket is the same as the TODO here: https://github.com/mongodb/mongo/blob/e5e4a2427b869e40f1a1e6f65dc5e3fd11f451ac/src/mongo/db/query/planner_access.cpp#L1126.
Currently, when we try to perform an indexed sort by scanning the whole index from MinKey to MaxKey, we always add a FETCH as the parent of the index scan. The FETCH is usually necessary, but may not be if the query is covered by the index.
Example:
> t = db.t
|
> t.drop()
|
true
|
> t.ensureIndex({a: 1, b: 1})
|
> t.find({b: {$gte: 0}}, {_id: 0, b: 1}).sort({a: 1})
|
The indexed solution for this example is a scan over the entire index {a: 1, b: 1}, followed by a FETCH, followed by a PROJ:
PROJ
|
---proj = { _id: 0.0, b: 1.0 }
|
---fetched = 1
|
---sortedByDiskLoc = 0
|
---getSort = []
|
Child:
|
------FETCH
|
---------filter:
|
b $gte 0.0 First: notFirst: full path:
|
---------fetched = 1
|
---------sortedByDiskLoc = 0
|
---------getSort = [{ a: 1 }, { a: 1, b: 1 }, ]
|
---------Child:
|
------------IXSCAN
|
---------------keyPattern = { a: 1.0, b: 1.0 }
|
---------------direction = 1
|
---------------bounds = field #0['a']: [MinKey, MaxKey], field #1['b']: [MinKey, MaxKey]
|
---------------fetched = 0
|
---------------fetched = 0
|
---------------sortedByDiskLoc = 0
|
---------------getSort = [{ a: 1 }, { a: 1, b: 1 }, ]
|
Since the value of "b" is provided by the index, the FETCH is unnecessary---in other words, this should execute as a covered query.
Attachments
Issue Links
- is duplicated by
-
SERVER-20433 Unexpected non-covered query in 3.0 and 2.6 (that is covered in 2.4)
-
- Closed
-
- is related to
-
SERVER-45011 Index used for whole IXSCAN plan is determined by index creation order
-
- Closed
-