If a $or clause is { a:

, b:1 } and the shard key is

, the a range 0 < a < 1 can be eliminated from subsequent field range sets. Currently only the combined range 0 < a < 1 AND b = 1 is eliminated, because the shard key is not supplied when advancing to the next $or clause.

            if (!org.orRangesExhausted())
                org.popOrClauseSingleKey();

We'd want something like popOrClause, but which takes a shard key instead of a real index and applies it to the single key field range set.

        /** Iterates to the next $or clause by removing the current $or clause. */
        void popOrClause( NamespaceDetails *nsd, int idxNo, const BSONObj &keyPattern );
        void popOrClauseSingleKey();

This filtering can reduce the overlap of chunk ranges that need to be scanned to determine the set of target shards. In simple cases this change will not likely provide much of a performance improvement, but it would make the sharded and unsharded uses of OrRangeGenerator a bit more uniform.