[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: |
|
||||||||
| 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? |