-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
ALL
-
Execution Team 2021-05-17, Execution Team 2021-05-31
Wildcard indexes may have many (an unbounded number of) multi-key paths, one multi-key path for every path to an array in any document.
e.g. something like
{_id: <>, a: [40, 30]} => "a" (multi-key path)
{_id: <>, a: {b: [40, 30]}} => "a.b" (multi-key path)
Rather than storing the multi-key path in the mdb catalog entry for the index, the multi-key paths for wildcard indexes are stored in the index table, as a KeyString. There is a reserved range of record IDs for multi-key paths, and a special RecordID constant is used in the KeyString (which is the 'key' with the record ID appended at the end).
However, clustered indexes use RecordID strings as opposed to int64 for regular indexes. There is an expectation in the WiredTigerIndex layer such that an overall index has a KeyFormat of either string or int64, and it checks for that type. Therefore, we run into problems with a clustered wildcard index specially handling multi-key with an int64, and then the lower code layer expects a string.
Furthermore, clustered indexes strings were designed to support many different types, wherein timestamps is just one among many. We need to figure out how to either reserve a safe range of RecordIDs for string RecordID multi-key path documents; or otherwise flag a KeyString as a wildcard multi-key path entry.
- is duplicated by
-
SERVER-55741 Add multi-key wildcard index testing for time-series because such indexes have special handling internally
- Closed