MongoDB | 2657151

Info

> 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.

Top User Comments

Steps to Reproduce