Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-36794

Non-blocking $text plans with just one search term do not need an OR stage

    XMLWordPrintable

Details

    • Fully Compatible
    • Query Optimization 2021-02-22

    Description

      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).

      Attachments

        Issue Links

          Activity

            People

              hartek.sabharwal@mongodb.com Hartek Sabharwal
              david.storch@mongodb.com David Storch
              Votes:
              2 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: