[SERVER-56480] allPlansExecution array shows extraneous execution stats when multi-planning did not occur Created: 29/Apr/21  Updated: 29/Oct/23  Resolved: 26/May/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.0.0-rc0, 5.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: David Storch Assignee: Irina Yatsenko (Inactive)
Resolution: Fixed Votes: 0
Labels: neweng, post-rc0, sbe-post-rc0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v5.0
Sprint: Query Execution 2021-05-31
Participants:

 Description   

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.



 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 26/May/21 ]

Author:

{'name': 'Irina Yatsenko', 'email': 'irina.yatsenko@mongodb.com', 'username': 'IrinaYatsenko'}

Message: SERVER-56480 Set executionStats.allPlansExecution to an empty array when using a single plan solution

(cherry picked from commit cb26584ed0dcbf5c3736c01bd7fb2636babed312)
Branch: v5.0
https://github.com/mongodb/mongo/commit/ae1f7598539e1e8a3ce1960fdd0f6b2a61ead9a9

Comment by Irina Yatsenko (Inactive) [ 26/May/21 ]

Even though the change affects `explain` output, it brings it back to the prior released behaviour (the fix will be ported to 5.0 as well) so no downstream notice needed.

Comment by Githook User [ 26/May/21 ]

Author:

{'name': 'Irina Yatsenko', 'email': 'irina.yatsenko@mongodb.com', 'username': 'IrinaYatsenko'}

Message: SERVER-56480 Set executionStats.allPlansExecution to an empty array when using a single plan solution
Branch: master
https://github.com/mongodb/mongo/commit/cb26584ed0dcbf5c3736c01bd7fb2636babed312

Generated at Thu Feb 08 05:39:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.