[SERVER-5904] embedded doc matches could use dotted field indexes Created: 23/May/12  Updated: 06/Dec/22  Resolved: 09/Oct/17

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 2.1.1
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Randolph Tan Assignee: Backlog - Query Team (Inactive)
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-2953 Use dotted indexes for embedded docum... Backlog
Related
related to SERVER-2953 Use dotted indexes for embedded docum... Backlog
Assigned Teams:
Query
Backwards Compatibility: Fully Compatible
Participants:
Case:

 Description   

Ex:

db.user.ensureIndex({ "a.x": 1 })
db.user.insert({ a: { x: 1, y: 2 }});
db.user.find({ "a.x": 1 }).explain(); // uses index
db.user.find({ a: { x: 1 }}).explain(); // doesn't use index

Both queries gives you the expected result but the latter doesn't use an index.



 Comments   
Comment by Asya Kamsky [ 09/Oct/17 ]

This behavior is correct since the syntax

db.user.find({ a: { x: 1 }})

does not match the given document, but only a being exactly subdocument {x:1} and it will use index on "a" for that query.

Comment by Eliot Horowitz (Inactive) [ 11/Jun/12 ]

If you try both queries, the first will match the document inserted, the 2nd will not.

Comment by James Roper [ 11/Jun/12 ]

Are they really semantically different? What's a result that could be returned by one and not the other?

If there is such a result, then it would seem to me that the second queries results would always be a subset of the first queries results, hence the second query could use the index, and then apply further filtering.

As it stands, it would be very easy for someone to create the correct indexes, but, without realising, not be using them (until they encounter a massive performance issue in production).

Comment by Eliot Horowitz (Inactive) [ 23/May/12 ]

semantically different, so not sure what the right approach is.

Generated at Thu Feb 08 03:10:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.