[SERVER-16330] plan cache filters aren't applied if mongoS rewrites the projection of a query Created: 26/Nov/14  Updated: 04/Feb/15  Resolved: 16/Dec/14

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

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

Attachments: File filterfailure.js    
Issue Links:
Duplicate
duplicates SERVER-13008 Encoding of projection for query plan... Closed
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

See attached js, should not succeed if filters are used on mongoS.

Participants:

 Description   

If mongoS changes the projection on a query, then the filters aren't applied to the query at all (mongoD runs the normal ranking process).

The expected behavior would be either:

  1. Apply the filters as mongoD without the modified project (easier for users to understand)
  2. Apply the filters to query as given to mongoD from mongoS


 Comments   
Comment by David Storch [ 01/Dec/14 ]

Hi charlie.page@10gen.com,

As far as I can tell from the attached repro script, this is Works as Designed. It is the case that the index filters are not aware of projection rewrites performed by mongos, and therefore that these rewrites must be taken into account when setting filters on the shards. However, in the filterfailure.js script, the index filter doesn't get applied through mongos because mongos is not performing any rewrite.

To be more specific, the mongos query in question is

mongos.getDB("db").foo.find({a:1}, {a:1}).sort({b:1});

The following elements of this query determine the plan cache key:

  • query of {a: 1},
  • projection of {a: 1}
  • sort of {b: 1}

The index filter, anticipating that mongos will rewrite the projection to include the sort key, is set with the following plan cache key:

  • query of {a: 1},
  • projection of {a: 1, b: 1}
  • sort of {b: 1}

In this case, the collection is not sharded, so the query is simply forwarded to the shard which owns the collection. Since there is just one shard involved, the projection and sort can be forwarded to the shard as is. The sort stage is then performed on the shard alone (mongos does not participate in the sorting). This behavior is clear from a 2.8-style explain of this query:

> mongos.getDB("db").foo.find({a:1}, {a:1}).sort({b:1}).explain("queryPlanner");
{
	"queryPlanner" : {
		"mongosPlannerVersion" : 1,
		"winningPlan" : {
			"stage" : "SINGLE_SHARD",
			"shards" : [
				{
					"shardName" : "shard0000",
					"connectionString" : "localhost:30000",
					"serverInfo" : {
						"host" : "dstorch-desktop",
						"port" : 30000,
						"version" : "2.8.0-rc2-pre-",
						"gitVersion" : "977abaaba51aeda3b4c6f0774aeb66b41aaa2274"
					},
					"plannerVersion" : 1,
					"parsedQuery" : {
						"a" : {
							"$eq" : 1
						}
					},
					"winningPlan" : {
						"stage" : "PROJECTION",
						"transformBy" : {
							"a" : 1
						},
						"inputStage" : {
							"stage" : "SORT",
							"sortPattern" : {
								"b" : 1
							},
							"inputStage" : {
								"stage" : "KEEP_MUTATIONS",
								"inputStage" : {
									"stage" : "FETCH",
									"inputStage" : {
										"stage" : "IXSCAN",
										"keyPattern" : {
											"a" : 1
										},
										"isMultiKey" : false,
										"direction" : "forward",
										"indexBounds" : {
											"a" : [
												"[1.0, 1.0]"
											]
										}
									}
								}
							}
						}
					},
					"rejectedPlans" : [ ]
				}
			]
		}
	},
	"ok" : 1
}

Since the projection received by mongod is {a: 1} and not {a: 1, b: 1}, it is expected that the index filter will not be applied. I'm closing as Works as Designed for now. Feel free to reopen if there are remaining concerns.

Best,
Dave

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