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

allPlansExecution array shows extraneous execution stats when multi-planning did not occur

    • Fully Compatible
    • ALL
    • v5.0
    • Query Execution 2021-05-31

      This is a regression in 5.0 and does not affect previous verisons.

      In 4.4 and all previous versions, the allPlansExecution section is empty when there is just one candidate plan. As a simple example, consider this query which has only a collection scan plan:

      MongoDB Enterprise > db.c.find().explain(true)
      {
      	"queryPlanner" : {
      		"plannerVersion" : 1,
      		"namespace" : "test.c",
      		"indexFilterSet" : false,
      		"parsedQuery" : {
      
      		},
      		"winningPlan" : {
      			"stage" : "COLLSCAN",
      			"direction" : "forward"
      		},
      		"rejectedPlans" : [ ]
      	},
      	"executionStats" : {
      		"executionSuccess" : true,
      		"nReturned" : 2,
      		"executionTimeMillis" : 0,
      		"totalKeysExamined" : 0,
      		"totalDocsExamined" : 2,
      		"executionStages" : {
      			"stage" : "COLLSCAN",
      			"nReturned" : 2,
      			"executionTimeMillisEstimate" : 0,
      			"works" : 4,
      			"advanced" : 2,
      			"needTime" : 1,
      			"needYield" : 0,
      			"saveState" : 0,
      			"restoreState" : 0,
      			"isEOF" : 1,
      			"direction" : "forward",
      			"docsExamined" : 2
      		},
      		"allPlansExecution" : [ ]  <--------------- Empty!
      	},
      	"serverInfo" : {
      		"host" : "storchbox",
      		"port" : 27017,
      		"version" : "4.4.4",
      		"gitVersion" : "8db30a63db1a9d84bdcad0c83369623f708e0397"
      	},
      	"ok" : 1
      }
      

      The rationale for this behavior is that the allPlansExecution section displays information about the multi-planning trial period. It can help you diagnose why one plan is chosen over another. However, if there is just one plan, then there is no trial execution period, and therefore the allPlansExecution information describing this trial period should be omitted.

      In the master branch, we have introduced a regression where a query with just a single candidate plan displays duplicate information about that plan in the allPlansExecution section:

      MongoDB Enterprise > db.c.find().explain(true)
      MongoDB Enterprise > db.c.find().explain(true)
      {
      	"explainVersion" : "1",
      	"queryPlanner" : {
      		"namespace" : "test.c",
      		"indexFilterSet" : false,
      		"parsedQuery" : {
      
      		},
      		"maxIndexedOrSolutionsReached" : false,
      		"maxIndexedAndSolutionsReached" : false,
      		"maxScansToExplodeReached" : false,
      		"winningPlan" : {
      			"stage" : "COLLSCAN",
      			"direction" : "forward"
      		},
      		"rejectedPlans" : [ ]
      	},
      	"executionStats" : {
      		"executionSuccess" : true,
      		"nReturned" : 3,
      		"executionTimeMillis" : 0,
      		"totalKeysExamined" : 0,
      		"totalDocsExamined" : 3,
      		"executionStages" : {
      			"stage" : "COLLSCAN",
      			"nReturned" : 3,
      			"executionTimeMillisEstimate" : 0,
      			"works" : 5,
      			"advanced" : 3,
      			"needTime" : 1,
      			"needYield" : 0,
      			"saveState" : 0,
      			"restoreState" : 0,
      			"isEOF" : 1,
      			"direction" : "forward",
      			"docsExamined" : 3
      		},
      		"allPlansExecution" : [     <----- Duplicated info about the lone plan!
      			{
      				"nReturned" : 0,
      				"executionTimeMillisEstimate" : 0,
      				"totalKeysExamined" : 0,
      				"totalDocsExamined" : 0,
      				"executionStages" : {
      					"stage" : "COLLSCAN",
      					"nReturned" : 0,
      					"executionTimeMillisEstimate" : 0,
      					"works" : 0,
      					"advanced" : 0,
      					"needTime" : 0,
      					"needYield" : 0,
      					"saveState" : 0,
      					"restoreState" : 0,
      					"isEOF" : 0,
      					"direction" : "forward",
      					"docsExamined" : 0
      				}
      			}
      		]
      	},
      	"command" : {
      		"find" : "c",
      		"filter" : {
      
      		},
      		"$db" : "test"
      	},
      	"serverInfo" : {
      		"host" : "storchbox",
      		"port" : 27017,
      		"version" : "5.0.0-alpha",
      		"gitVersion" : "unknown"
      	},
      	"serverParameters" : {
      		"internalQueryFacetBufferSizeBytes" : 104857600,
      		"internalQueryFacetMaxOutputDocSizeBytes" : 104857600,
      		"internalLookupStageIntermediateDocumentMaxSizeBytes" : 104857600,
      		"internalDocumentSourceGroupMaxMemoryBytes" : 104857600,
      		"internalQueryMaxBlockingSortMemoryUsageBytes" : 104857600,
      		"internalQueryProhibitBlockingMergeOnMongoS" : 0,
      		"internalQueryMaxAddToSetBytes" : 104857600,
      		"internalDocumentSourceSetWindowFieldsMaxMemoryBytes" : 104857600
      	},
      	"ok" : 1
      }
      

      This explain was generated from the classic execution engine, but the same problem exists when SBE is enabled. Furthermore, I suspect that the issue was introduced in development of the SBE project, since supporting explain for SBE required some surgery to the explain code.

            Assignee:
            irina.yatsenko@mongodb.com Irina Yatsenko (Inactive)
            Reporter:
            david.storch@mongodb.com David Storch
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: