-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Index Maintenance
-
Fully Compatible
-
Query Execution 2021-03-08, Query Execution 2021-03-22, Query Execution 2021-04-05, Query Execution 2021-04-19, Query Execution 2021-05-03
At present, an index's signature - that is, the combination of parameters which uniquely identify the index - is defined by its keypattern and collation. No index can be created if its signature is equivalent to an existing index. SERVER-25023 seeks to add the partialFilterExpression parameter to this list, such that multiple partial indexes could be built on the same fields so long as their filters are different.
We should also add the wildcardProjection parameter to the index signature. At present, we allow any number of wildcard indexes to be built using the {"field.path.$**": 1} notation, but we do not allow multiple wildcard indexes with different projections to exist. It is therefore legal to do this:
db.coll.createIndex({"a.$**": 1}) db.coll.createIndex({"b.$**": 1})
... but illegal to do the following, even though the indexes should be functionally identical to the above:
db.coll.createIndex({"$**": 1}, {wildcardProjection: {a: 1}}) db.coll.createIndex({"$**": 1}, {wildcardProjection: {b: 1}})
More significantly, the former syntax is limited to inclusion of a single path; permitting the latter would be far more powerful in allowing the user to create separate wildcard indexes to index different sections of their dataset.
- is related to
-
SERVER-25023 no way to index the same fields with two different partial index filters
- Closed
-
SERVER-47657 Add 'unique' and 'sparse' parameters to index signature
- Closed
- related to
-
SERVER-62636 setFeatureCompatibilityVersion 4.4 succeeds on 5.0 binVersion that has indexes with conflicting options
- Closed
-
SERVER-67446 Ensure consistent wildcardProjection and columnstoreProjection specs in catalog
- Closed