[SERVER-26833] Permit non-blocking $text queries when user doesn't request score projection Created: 28/Oct/16  Updated: 30/Apr/20  Resolved: 20/Oct/17

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: 3.6.0-rc1

Type: Improvement Priority: Major - P3
Reporter: Chris Harris Assignee: Justin Seyster
Resolution: Done Votes: 8
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-28060 Some words make simple full text sear... Closed
Related
related to SERVER-26534 Text search uses excessive memory Backlog
related to SERVER-47848 Aggregation fails to optimize TEXT_OR... Closed
related to SERVER-36794 Non-blocking $text plans with just on... Closed
Backwards Compatibility: Fully Compatible
Sprint: Query 2017-09-11, Query 2017-10-02, Query 2017-10-23
Participants:
Linked BF Score: 0

 Description   

The score calculation is currently always performed for a `$text` query. This is a blocking operation that delays the initial batch from being returned to the client. If this meta data is not requested by the client then we can optimize query execution by bypassing this calculation.



 Comments   
Comment by Githook User [ 19/Oct/17 ]

Author:

{'email': 'justin.seyster@mongodb.com', 'name': 'Justin Seyster', 'username': 'jseyster'}

Message: 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.
Branch: master
https://github.com/mongodb/mongo/commit/fc252a557434e988f63ea2dc54c06b7a508ef34f

Comment by Michael Dikman [ 16/Dec/16 ]

Any update on ETA for this one?
Is there any way or workaround we can do to be able to use the text based index search?

Comment by J Rassi [ 28/Oct/16 ]

This will involve changing TextStage::buildTextTree() to construct an OrStage instead of a TextOrStage, if the user didn't request a score in the projection.

Generated at Thu Feb 08 04:13:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.