Imagine you have fields A & B and a compound index defined as
{ A :1, B:1}
Now imagine a query
find( { B : value }).sort(A)
In 2.4 it appears we would jump to all values of A and within each subset of A skip to entries where B="value" in the index. Leading to a smaller nscannedObjects() value in the query plan.
As of 2.6 it appears indexed plans where the first field in the index is unconstrained are not considered. Which means we end up not using plans in 2.6 that would sometimes get used in 2.4
In this particular case, we end up essentially doing a full index scan. Which depending on data distribution, will most likely be slower than in 2.4.
- duplicates
-
SERVER-13197 Tighten index bounds and allow compound index to be chosen when predicate on leading field is not provided
- Backlog