[SERVER-85587] Add a new mode to explain which reports "allPlansExecution" but does not fully execute the winning plan Created: 23/Jan/24  Updated: 06/Feb/24

Status: Backlog
Project: Core Server
Component/s: Query Planning
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: David Storch Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Optimization
Participants:

 Description   

Today's behavior of the "queryPlanner" explain verbosity is that it generates the set of candidate plans, passes these plans to the multi-planner, and uses the plan ranker to select a winner. The winner and rejected plans are all reported, without any accompanying execution stats.

Despite the lack of execution stats, the multi-planning trial period took place in order to choose the winning plan. This means that the system has gathered the execution stats from the trial period, but does not report them. This ticket proposes a new explain mode which behaves like "queryPlanner" but also reports the trial period information – presumably in the usual "allPlansExecution" format. If a user wants to see information about the trial period today, they must instead run explain at "executionStats" or "allPlansExecution" verbosity, which also has the adverse effect of running the winning plan to completion.

I imagine that this new explain mode could be particularly useful when diagnosing a plan selection problem that results in an extremely slow plan. Imagine, for instance, that a multi-planning bug in a customer environment is selecting a plan which does a very large index scan. The customer may wish to try to reproduce this problem using explain in order to gather diagnostics about the plan selection behavior – without taking the performance penalty associated with actually executing the very unselective and thus very slow winning index scan plan.


Generated at Thu Feb 08 06:58:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.