[SERVER-35748] Allow MultikeyPaths to accept 'allPaths' metadata format Created: 22/Jun/18  Updated: 06/Dec/22  Resolved: 30/Jul/18

Status: Closed
Project: Core Server
Component/s: Index Maintenance, Querying
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Bernard Gorman Assignee: Backlog - Query Team (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-36109 Provide planner with multikeyness inf... Closed
Assigned Teams:
Query
Participants:

 Description   

Currently, IndexAccessMethod tracks multikey paths as an std::vector<std::set<std::size_t>> with size equal to the number of elements in the index key pattern. Each element in the vector is an ordered set of path-component indices that represent which path-prefixes of the corresponding indexed field cause the index to be multikey.

For allPaths indexes, we do not know how many elements are in the key pattern, and multikey paths are instead represented in the form {{{ 1: "path.to.array" }}}. We must rework the MultikeyPaths structure to enable it to accept metadata in this format.



 Comments   
Comment by Bernard Gorman [ 10/Jul/18 ]

david.storch, some rough initial thoughts: if we consider the star index to be a set of fixed-size single-field indexes, then I believe we can represent the MultikeyPaths as an std::map<string, std::vector<std::set<std::size_t>>> where each key is a fully-qualified path. We would need to rewrite MultiKeyPaths as a class hierarchy rather than a simple typedef, such that e.g. MultikeyFixedIndexPaths retains the current behaviour for fixed indexes while MultikeyStarIndexPaths allows us to track all path-masks across all known paths; it would not be difficult to build these up while traversing each document to extract the keys. When considering a given path in the star index during planning, the MultikeyStarIndexPaths could then return the familiar std::vector<std::set<std::size_t>> mask for that specific path.

I'm sure there are complications that may present themselves in the course of this work, but in the abstract this seems feasible and a comfortable fit for the existing mechanisms. Does this make sense to you?

Comment by David Storch [ 25/Jun/18 ]

bernard.gorman, can you describe how you plan to rework MultikeyPaths? We still need a representation for the fixed-sized multikey paths associated with a regular index key pattern, so this work shouldn't take that away?

Generated at Thu Feb 08 04:40:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.