Details
-
Bug
-
Resolution: Unresolved
-
Critical - P2
-
None
-
5.1.1, 5.2.0-rc1, 6.0.12, 7.0.4
-
None
-
Query Execution
-
ALL
-
QE 2022-01-24, QO 2023-11-13, QO 2023-11-27
-
(copied to CRM)
Description
Currently, the strategy used in SBE multiplanning is as follows:
- We run non blocking plans before blocking ones.
- We run each plan’s trial period to completion (i.e. until we return 101 documents or we use up the plans budget). We use the number of reads performed by said plan to bound the number of reads used by any remaining plans.
The problem with this approach is that if the first plan we run is not the optimal one, we are stuck running it and we can potentially use all of the reads. As an example, consider two plans, A and B. Plan A needs to perform 10k storage engine reads to get 101 documents, while plan B needs to perform 101 reads to get 101 documents. If Plan B runs first, we have no problems: we will set the reads limit for plan A to 101, and it will stop running after 101 reads. If Plan A runs first however, we will be stuck running plan A for all 10k reads. Though we’ll eventually run plan B and it will be chosen, this negatively impacts the performance of queries which need to use the multiplanner.
Attachments
Issue Links
- is duplicated by
-
SERVER-82549 MongoDB 7.0.2 SBE query slow when direct index exists
-
- Closed
-
- is related to
-
SERVER-83196 SBE multiplanning may chooses the wrong plan
-
- Open
-
- related to
-
SERVER-82677 Deduplicate index scan + fetch plans guaranteed to have similar performance
-
- In Code Review
-
-
SERVER-62981 Make SBE multi-planner's trial period termination condition independent of collection size
-
- Closed
-
-
SERVER-63102 Make separate internalQueryPlanEvaluationWorks knobs for the classic and SBE multi-planners
-
- Closed
-
-
SERVER-63642 Add serverStatus metrics to measure multi-planning performance
-
- Closed
-
-
SERVER-63641 Improve SBE multi-planning by choosing which plan to work next based on a priority metric
-
- Closed
-
- links to