Priority: Major - P3
Affects Version/s: None
Fix Version/s: None
I've always believed from documentation that only single field sparse index were supported.
Doing quick testing, it turns out:
- compound sparse index creates fine
- the behavior is that it is only sparse if all fields are non existent
I feel like the behavior is not useful at all: it's rare that all fields are absent and thus it mostly behaves like a non-sparse.
The more common use case is as follows:
- a sparse field tells if doc should be included in index
- compound on other fields to do further matching an sorting, like time etc
Say I'm working on reconciliation software: 99% of my records are matched and 1% non matched.
I need to do fast operations on non-matched items that may include complex matching and sorting.
Right now if I want to compound the index, all 100% records will be in index tree.
Ideally I just have a sparse flag "unmatched: true" and can compound freely
and obtain an index that's 99% smaller.
Today the only solution is to somehow encode information into the "unmatched" field.