-
Type:
Improvement
-
Status: Closed
-
Priority:
Major - P3
-
Resolution: Fixed
-
Affects Version/s: 2.6.1
-
Component/s: Querying
-
Backwards Compatibility:Fully Compatible
-
Backport Requested:v4.0, v3.6, v3.4
-
Epic Link:
-
Sprint:Query 2018-07-02, Query 2018-07-16, Query 2018-07-30
-
Case:
Suppose we have a query for which the following conditions hold:
- The query predicates can all be answered using an index.
- The query is not covered (i.e. it requires a fetch stage) because there is no projection.
- There is a large skip value.
Currently, we will fetch documents for all the skipped results. This means unnecessary IO / unnecessarily large nscannedObjects. As an optimization, we could avoid the extra fetching by putting the skip stage below the fetch.
As an example, say we have documents of the form {a: <int>, b: <int>, c: <int>, x: <int>} and an index {a: 1, b: 1, c: 1}. The following query
db.coll.find({a: 3, b: 4}).sort({c: 1}).skip(10000);
|
can use the index to answer both query predicates and to do the sort. However, the query is not covered: we need to fetch documents in order to get the '_id' and 'x' fields. In this case it is possible to put the skip stage below the fetch in order to avoid fetching the 10,000 skipped documents.
- is duplicated by
-
SERVER-15169 performance regression in .skip() using btree cursor
-
- Closed
-
-
SERVER-2845 when using skip, objects still reported as being scanned.
-
- Closed
-
-
SERVER-24025 Don't load .skip()ed documents when possible.
-
- Closed
-
- related to
-
SERVER-14663 Put skip stage below projection
-
- Open
-