Document caveats around $allMatch, $elemMatch, etc.
- Dominant language
- Erlang
- Stars
- 7k
- Forks
- 1.1k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 9
Description
As documented in [another issue](https://github.com/apache/couchdb/issues/2236), some selectors incur performance costs [because they do not map to how views work](https://github.com/apache/couchdb/issues/2236#issuecomment-538928959). However, only `$regex` is identified as not functioning with indices. All such operators that incur these unexpected costs should be documented.
## Expected Behavior
Performance caveats for Mango operators are documented clearly.
## Current Behavior
Performance caveats are only documented for `$regex`.
Contributor guide
Research direction
Start with the Mango selector documentation and the linked issue #2236, then compare the documented $regex behavior with operators such as $allMatch and $elemMatch. Document the relevant performance and index-use caveats clearly for all affected operators.
Written by the indexing model from the issue text.
Assessment
- Domain
- databases, documentation
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100