|
To provide a bit more detail, this ticket suggests changing the definition of multikeyness metadata for index key patterns with positional components such as {"a.0": 1}. To provide a concrete example, imagine that you have the index {"a.0": 1} and the user inserts the document {a: [1, 2, 3]}. For all index versions existing today, path "a" will not be considered multikey in this scenario. This means that for indexes with positional path components, the query optimizer cannot rely on the multikeyness metadata in order to determine whether "a" is ever an array. The whole purpose of the multikeyness metadata is to be able to detect definitively when an indexed path component never contains an array, since this can permit certain beneficial optimizations (such as tighter index bounds). Therefore, it would be an improvement to track paths containing arrays as multikey even if those arrays are positionally indexed.
After some discussion, we've decided that this change would require a bump of the index version, so we have labeled this ticket "indexv3". The old definition of multikeyness for positional path components would continue to apply for v:2 and earlier indexes, but the new definition would apply for v:3 indexes. This way, the optimizer could know to interpret the multikeyness metadata differently for v:3 indexes. Also, it means that we could delete any code associated with the old multikeyness definition once v:2 indexes are no longer supported by the system.
|