[SERVER-67576] Make parameterized explode for sort plans work with the SBE plan cache Created: 27/Jun/22  Updated: 29/Oct/23  Resolved: 22/Mar/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.0.0-rc0

Type: Improvement Priority: Major - P3
Reporter: David Storch Assignee: Rui Liu
Resolution: Fixed Votes: 0
Labels: pm2697-m3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by COMPASS-6639 Investigate changes in SERVER-67576: ... Closed
Documented
is documented by DOCS-15972 [Server] Make parameterized explode f... Closed
Related
is related to SERVER-66459 Explode for sort caches incorrect par... Closed
Assigned Teams:
Query Execution
Backwards Compatibility: Minor Change
Sprint: QE 2023-02-06, QE 2023-02-20, QE 2023-03-06, QE 2023-03-20, QE 2023-04-03
Participants:
Story Points: 20

 Description   

In related ticket SERVER-66459 we plan to implement a quick fix of simply prohibiting query solutions generated by "explode for sort" from getting cached. The work for this ticket is to re-enable the SBE plan cache in combination with explode for sort.

Doing so could be a bit tricky. One reason is that the decision of whether to explode is done based on analyzing the index bounds. However, there could be various interval evaluation trees (IETs) that could lead to these explodable bounds. We need to make sure that no matter the value of the parameters, the SBE plan is still correct.

Another complication is that the number of index scans resulting from the explosion can depend on the number of unique values in a $in. But the current SBE plan cache encoding does not incorporate the length of the $in or the number of unique values. Doing so would make the plan cache less effective, since it would result in reduced plan reuse for applications that use $in.

One idea for how to implement this is to have some kind of runtime explosion. That is, the cached plan itself would not necessarily contain all of the necessary branches beneath the SortedMergeStage. When the plan is recovered from the cache and the input parameter values bound in, we can create the correct number of cloned ixscan branches beneath the sorted merge, each referring to the correct (lowKey, highKey) pair from the runtime environment.



 Comments   
Comment by Githook User [ 22/Mar/23 ]

Author:

{'name': 'Rui Liu', 'email': 'lriuui0x0@gmail.com', 'username': 'lriuui0x0'}

Message: SERVER-67576 Enable explode for sort query in SBE cache
Branch: master
https://github.com/mongodb/mongo/commit/04d45b9aa49ce891066735cd4dbeea97e9b55e34

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