-
Type:
Bug
-
Resolution: Works as Designed
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Optimization
-
ALL
> db.repro.insert({a: {b: 1}})
> db.repro.createIndex({"a.$**": 1}, {collation: {locale: 'en', numericOrdering: true}})
> db.repro.find({"a.b": 1}).explain()
winningPlan: {
stage: 'FETCH',
inputStage: {
stage: 'IXSCAN',
keyPattern: { '$_path': 1, 'a.b': 1 },
indexName: 'a.$**_1',
collation: {
locale: 'en',
caseLevel: false,
caseFirst: 'off',
strength: 3,
numericOrdering: true,
alternate: 'non-ignorable',
maxVariable: 'punct',
normalization: false,
backwards: false,
version: '57.1'
},
isMultiKey: false,
multiKeyPaths: { '$_path': [], 'a.b': [] },
isUnique: false,
isSparse: false,
isPartial: false,
indexVersion: 2,
direction: 'forward',
indexBounds: {
'$_path': [ '[CollationKey(0x612e62), CollationKey(0x612e62)]' ],
'a.b': [ '[1, 1]' ]
}
}
The bounds for "$_path" should be "a.b", but instead they are encoded using the collation of the query.
I am not sure this is actually a bug, but it is certainly unexpected. You could imagine a workload with documents that have field names with different cases and using a case insensitive collation may accidentally yield unexpected index bounds. We need to think more to understand if this could yield incorrect query results (perhaps in a covered plan?).
I am also not sure this is fixable without upgrading the index format.