On Aug 5, 2:44 pm, Scott Hernandez <scotthernan...@gmail.com> wrote:
> What is expected index use for queries with $or; should we consider
> them to be broken up as a combination of queries for each $or clause
> where the index for that clause will be used and then duplicates
> removed?
> sample doc: {_id:1, a:1, b:2, c:3}
> find({a:1, $or: [{b:2, c:3}]}) -> find({a:1, b:2}) + find({a:1, c:3}) = results?
Yeah, to get good worst case performance we do the clauses one at a
time. While evaluating clauses we check whether a given document
would have been returned as part of the scan for an earlier clause and
we shouldn't return it if so. There are some cases where we can avoid
looking at certain index ranges in later clauses because they have
already been explored in earlier clauses. We are going to increase
the scope of these optimizations for 1.8 - SERVER-1213
Also, I should mention that while you are doing the initial query the
full query optimizer is employed to choose the best index for each
clause. But once you start doing get mores, the index selection is
more primitive. This was requested behavior for 1.6, but we are going
to enhance for 1.8 - SERVER-1215.
> How does this change when sorting?
Right now if you have a sort spec the $or is completely ignored from
the perspective of indexing. This is another feature that was
designated for 1.8 and there is a bug for it SERVER-1205.
