[SERVER-36793] Ban $in queries for allPaths indices which contain unsupported values Created: 21/Aug/18  Updated: 10/Sep/18  Resolved: 10/Sep/18

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

Type: Bug Priority: Major - P3
Reporter: Ian Boros Assignee: Ian Boros
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-36731 Ban object inequality and $in with un... Closed
Sprint: Query 2018-09-24
Participants:

 Description   

Example:

db.c.drop();
 
assert.commandWorked(db.adminCommand({setParameter: 1, internalQueryAllowAllPathsIndexes: true}));
 
db.c.insert({a: 1});
db.c.insert({a: {b: 1}});
 
assert.commandWorked(db.c.createIndex({"$**":1}));
 
const query = {a: {$in: [1, {b: 1}]}};
printjson(db.c.find(query).toArray());
printjson(db.c.explain("allPlansExecution").find(query).finish());

This query will attempt to use an allPaths index. We should make sure that it doesn't.



 Comments   
Comment by Ian Boros [ 10/Sep/18 ]

I plan on doing this work under SERVER-36731.

Comment by David Storch [ 21/Aug/18 ]

If possible, we should partially index an $in, such as the one above, rather than failing to use the index for the $in entirely. This would likely involve "detaching" any predicates that are not compatible with the index from the $in MatchExpression node, and generating an $or MatchExpression node internally.

Generated at Thu Feb 08 04:44:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.