[SERVER-2109] Query optimizer should pick plans that can use covered indexes Created: 16/Nov/10  Updated: 12/Jul/16  Resolved: 02/Apr/14

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: 2.6.0-rc2

Type: Improvement Priority: Major - P3
Reporter: Eliot Horowitz (Inactive) Assignee: hari.khalsa@10gen.com
Resolution: Done Votes: 6
Labels: query_triage
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-192 query that just returns value in inde... Closed
Duplicate
is duplicated by SERVER-3611 CLONE - query that just returns value... Closed
is duplicated by SERVER-10728 Query optimizer should consider the p... Closed
is duplicated by SERVER-10767 Use index on find all Closed
Related
related to SERVER-801 query optimizer should consider full ... Closed
Participants:

 Comments   
Comment by Scott Hernandez (Inactive) [ 18/Feb/11 ]

No, for that to work you must exclude _id from the projection, and include the fields in the index; By default _id is always returned. The first one will never work since you aren't specifying a returned field restriction (projection).

http://www.mongodb.org/display/DOCS/Retrieving+a+Subset+of+Fields

Comment by Remon van Vliet [ 18/Feb/11 ]

I'm assuming this will work for both these cases? :

db.col.save(

{a:2, b:3}

)
db.col.ensureIndex(

{a:1, b:1}

)
db.col.find(

{a:2}

) <- covered query

as well as :

db.col.save(

{a:2, b:3}

)
db.col.ensureIndex(

{a:1}

)
db.col.find(

{a:2}

,

{a:1}

) <- covered query

?

Comment by Eliot Horowitz (Inactive) [ 14/Dec/10 ]

lets talk about this one

Comment by Eliot Horowitz (Inactive) [ 21/Nov/10 ]

Yes.
Right now if it happens to use an index that contains all the info needed, doesn't need data.

Comment by Testo [ 21/Nov/10 ]

you mean that if this feature is implemented, it will be able to query just the index to return the value if the requested field list is already covered by the index?

Generated at Thu Feb 08 02:59:00 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.