SERVER-26833 Non-blocking text queries when projection ignores score.

With this change, text queries use the non-blocking OR stage in place
of the blocking TEXT_OR stage when it is not necessary to compute the
text score (because the projection does not call for it).

We also removed the unnecessary MatchableTextDocument object with this
change. This object was used in the TEXT_OR stage to apply a filter to
index entries. The query planner adds search predicates as a filter in
the OR/TEXT_OR stage when they can be covered by the index, allowing
them to get filtered out before the full document need be examined

However, the OR stage uses an IndexMatchableDocument which does almost
the same thing. The only difference is that TextMatchableDocument will
fetch documents if the index does not cover the filter. Since that
should never happen (if the query planner is doing its job right), we
shouldn't need TextMatchableDocument.

1 files changed, 13 insertions, 0 deletions

diff --git a/jstests/aggregation/bugs/server11675.js b/jstests/aggregation/bugs/server11675.js
index 168b745f201..c80f9a38af5 100644
--- a/jstests/aggregation/bugs/server11675.js
+++ b/jstests/aggregation/bugs/server11675.js
@@ -43,6 +43,19 @@ var server11675 = function() {
 
         var findRes = cursor.toArray();
         var aggRes = t.aggregate(pipeline).toArray();
+
+        // If the query doesn't specify its own sort, there is a possibility that find() and
+        // aggregate() will return the same results in different orders. We sort by _id on the
+        // client side, so that the results still count as equal.
+        if (!query.hasOwnProperty("sort")) {
+            findRes.sort(function(a, b) {
+                return a._id - b._id;
+            });
+            aggRes.sort(function(a, b) {
+                return a._id - b._id;
+            });
+        }
+
         assert.docEq(aggRes, findRes);
     };