Regarding the processing done example - Just noting what was said later (with the partial index use case) that if we query and select very few documents then the right most part of index is frequently used for READING but to get performance gains the WRITES must also be only the right most part (like an incrementing values) [therefor partial index can be used to make sure also writes are only for the selective collection subset]
The country, state, zip code example vs the processing, Done example seem to conflate.. but thinking about it seems that they are different issues: 1. processing, done - you can index low cardinality fields based on what you query If your query selects only few documents then that's good This is if after the index search we left with small amount of un indexed documents (the list in the index leaves showed at the beginning). 2. country, state, zip code - (index order of equality fields) since our query is selecting the exact same amount of documents (the list in the index leaves) in both ways the indexes are compounded then the only difference is the length of traversal to the leaves - which is exactly the same since both trees have the same height (Log N) Wanted to write it to myself if ever watching this again, though it could also help someone else.. so adding it as comment :)
✅ Sign-up for a free MongoDB Atlas cluster at → trymongodb.com/3K5rhNP
✅ Learn more about MongoDB Indexes → trymongodb.com/3UEOOdF
✅ Explore MongoDB performance monitoring →trymongodb.com/3K44l1q
✅ mdb.link/subscribe
Regarding the processing done example -
Just noting what was said later (with the partial index use case) that if we query and select very few documents then the
right most part of index is frequently used for READING but to get performance gains the WRITES must also be only the right most part
(like an incrementing values)
[therefor partial index can be used to make sure also writes are only for the selective collection subset]
The country, state, zip code example vs the processing, Done example seem to conflate.. but thinking about it seems that they are different issues:
1. processing, done - you can index low cardinality fields based on what you query
If your query selects only few documents then that's good
This is if after the index search we left with small amount of un indexed documents (the list in the index leaves showed at the beginning).
2. country, state, zip code - (index order of equality fields) since our query is selecting the exact same amount of documents (the list in the index leaves)
in both ways the indexes are compounded then the only difference is the length of traversal to the leaves - which is exactly the same since
both trees have the same height (Log N)
Wanted to write it to myself if ever watching this again, though it could also help someone else.. so adding it as comment :)
need to watch this one again.. wasn't easy