[SERVER-6506] avoid checking for match of a full document field in certain cases where the field was already matched in the index Created: 18/Jul/12  Updated: 14/Apr/16  Resolved: 26/Jan/15

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

Type: Improvement Priority: Major - P3
Reporter: Aaron Staple Assignee: David Storch
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
duplicates SERVER-10026 New query system Closed
Related
is related to SERVER-4207 $in queries perform linearly to the l... Backlog
Backwards Compatibility: Fully Compatible
Participants:

 Description   

In some cases where a large array is indexed and an (eg equality) match on (eg a non null value) is requested, it may be slow and unnecessary to scan the document's full array for a matching element. The existence of a matching element may be inferred from the existence of a matching index key. We'd need to carefully examine the set of cases where this optimization can be applied.



 Comments   
Comment by David Storch [ 26/Jan/15 ]

I think this has been resolved as part of the query system rewrite for 2.6 (see SERVER-10026). An equality query against an indexed array does not have to scan the entire array, but rather infers that the document matches due to the presence of the index key:

> db.version()
3.1.0-pre-
> t.drop()
true
> t.ensureIndex({a: 1})
{
	"createdCollectionAutomatically" : true,
	"numIndexesBefore" : 1,
	"numIndexesAfter" : 2,
	"ok" : 1
}
> t.insert({_id: 1, a: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]})
WriteResult({ "nInserted" : 1 })
> t.find({a: 3}).explain()
{
	"queryPlanner" : {
		"plannerVersion" : 1,
		"namespace" : "test.t",
		"indexFilterSet" : false,
		"parsedQuery" : {
			"a" : {
				"$eq" : 3
			}
		},
		"winningPlan" : {
			"stage" : "FETCH",
			"inputStage" : {
				"stage" : "IXSCAN",
				"keyPattern" : {
					"a" : 1
				},
				"indexName" : "a_1",
				"isMultiKey" : true,
				"direction" : "forward",
				"indexBounds" : {
					"a" : [
						"[3.0, 3.0]"
					]
				}
			}
		},
		"rejectedPlans" : [ ]
	},
	"serverInfo" : {
		"host" : "dstorch-desktop",
		"port" : 27017,
		"version" : "3.1.0-pre-",
		"gitVersion" : "d8628625507b7a6927f21b1f1f91d68201fe4030"
	},
	"ok" : 1
}

Note in the explain output above that there is no filter on the FETCH stage. This indicates that the matcher is never used to match the full array against the query predicate.

Resolving as a duplicate of SERVER-10026.

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