Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-23909

Allow "2d" indices to accept a collation

    • Type: Icon: Task Task
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Querying
    • None
    • Query Execution

      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.

            Assignee:
            backlog-query-execution [DO NOT USE] Backlog - Query Execution
            Reporter:
            david.storch@mongodb.com David Storch
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: