[SERVER-23909] Allow "2d" indices to accept a collation Created: 25/Apr/16  Updated: 06/Dec/22

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

Type: Task Priority: Major - P3
Reporter: David Storch Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-31444 Queries against multikey trailing fie... Closed
related to SERVER-21011 Certain queries against compound 2d/t... Closed
Assigned Teams:
Query Execution
Participants:

 Description   

The non-geo trailing fields of a compound "2d" index have special key generation rules which as described in SERVER-21011. In cases where a regular btree index would be multikey, "2d" index key generation results in a single key where the indexed values are stored as a single array (see the example below).

> db.c.drop()
true
> db.c.ensureIndex({a: "2d", "b.c": 1})
{
	"createdCollectionAutomatically" : true,
	"numIndexesBefore" : 1,
	"numIndexesAfter" : 2,
	"ok" : 1
}
> db.c.insert({a: [0, 0], b: [{c: 5}, {c: 6}]})
WriteResult({ "nInserted" : 1 })
> db.c.find().hint({a: "2d", "b.c": 1}).returnKey()
{ "a" : BinData(128,"wAAAAAAAAAA="), "b.c" : [ 5, 6 ] }

As a consequence, the planner will never generate bounds over the trailing fields of a "2d" index, but rather resorts to covered matching. This is enforced in the planning code in the following locations:

https://github.com/mongodb/mongo/blob/r3.3.5/src/mongo/db/query/planner_access.cpp#L325-L340
https://github.com/mongodb/mongo/blob/r3.3.5/src/mongo/db/query/planner_access.cpp#L352-L357

In the case of indices with a collation, however, covered matching is currently not legal. Therefore, there is currently no utility for the user in specifying a collation on a "2d" index, and doing so should result in an error. Once SERVER-21011 is fixed, however, we should be able to safely generate bounds over the trailing fields in many cases.

Once SERVER-21011 is fixed, the work for this ticket is as follows:

  • Add "2d" to the whitelist of index types that may accept a collation.
  • Update TwoDAccessMethod::getKeys() to convert string elements to their corresponding comparison keys.
  • Ensure that string comparisons done by a filter attached to the IXSCAN stage are done in the realm of collator-generated comparison keys. That is, strings inside comparison predicates in the filter must be converted to their corresponding CollatorInterface::ComparisonKey values.

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