-
Type:
Improvement
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Querying, Text Search
-
Fully Compatible
-
Query Optimization 2021-02-22
In SERVER-26534 we made an improvement to make $text queries which do not require text score metadata use the OR stage. This improves $text performance by making the plan non-blocking, and also reduces the memory footprint of the plan by avoiding the special TEXT_OR stage.
The $text execution code generates an OR plan even when it has just one child. This typically happens when the search text consists of a single token:
MongoDB Enterprise > db.c.find({$text: {$search: "foo"}}).explain("queryPlanner").queryPlanner.winningPlan
{
"stage" : "TEXT",
"indexPrefix" : {
},
"indexName" : "words_text",
"parsedTextQuery" : {
"terms" : [
"foo"
],
"negatedTerms" : [ ],
"phrases" : [ ],
"negatedPhrases" : [ ]
},
"textIndexVersion" : 3,
"inputStage" : {
"stage" : "TEXT_MATCH",
"inputStage" : {
"stage" : "FETCH",
"inputStage" : {
"stage" : "OR", // Note that this is an OR of just one child.
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"_fts" : "text",
"_ftsx" : 1
},
"indexName" : "words_text",
"isMultiKey" : true,
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "backward",
"indexBounds" : {
}
}
}
}
}
}
As an optimization, we could eliminate the OR stage when it would have just one child. One major advantage of this change is that it would reduce the memory footprint of the query. The OR stage is known to consume too much memory in some cases, as it keeps a set of RecordIds for deduping (see SERVER-24375).
- is related to
-
SERVER-24375 Deduping in OR, SORT_MERGE, and IXSCAN (multikey case) uses unbounded memory
-
- Backlog
-
-
-
- Backlog
-
-
-
- Closed
-
-
-
- Closed
-