The planningTimeMicros metric indicates the time spent by the system in the query optimization phase, and appears in the logs and system.profile output. I believe it was first added in SERVER-70646 for version 6.2.
The current implementation incorporates the time spent enumerating and constructing plan alternatives, but it excludes the time spent in the multi-planner. This multi-planning phase can be quite expensive, since it is where we partially execute various candidate plans in order to gather runtime statistics. Furthermore, we've seen some reports of performance problems recently related to the SBE multi-planning implementation.
In order to make "planningTimeMicros" more useful for detecting performance problems related to multi-planning, we should change the implementation so that this metric incorporates time spent multi-planning. Preferably we would make sure it works this way for both the classic engine and SBE. An additional benefit of this change is that it will make the metric more meaningful to compare apples-to-apples against Bonsai optimization time, since in both cases we will be measuring the total time that the system takes to determine the optimal physical query plan.
- is duplicated by
-
SERVER-63015 Capture metrics about time spent multiplanning in slow query logs
- Closed
- is related to
-
SERVER-82549 MongoDB 7.0.2 SBE query slow when direct index exists
- Closed
-
SERVER-70646 Compute and add query planning time to PlanSummaryStats
- Closed