[SERVER-63031] Investigate replanning behaviour in cached solution planner Created: 27/Jan/22  Updated: 06/Dec/22  Resolved: 31/Mar/22

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

Type: Task Priority: Major - P3
Reporter: Anton Korshunov Assignee: Backlog - Query Execution
Resolution: Won't Do Votes: 0
Labels: new
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Execution
Participants:

 Description   

Currently there is this logic in SBE cached solution planner which seems suspicious as it's not quite obvious when a QueryPlanner could produce a single solution during replanning. The thinking is, if we get into the replanning logic, then we know that the cached plan has been picked up from multiple solutions, and since nothing has changed in the catalog meanwhile (otherwise the cached plan would have been invalidated and we would never pass through the cached solution planner) then the QueryPlanner should still produce multiple solutions during replanning.

david.storch suggested that in order to get into you would have to pick up a different view of the catalog in between making the decision to replan and calling QueryPlanner::plan() as part of the replanning operation. This seems potentially possible given that we can yield during the cached plan trial period, but a new catalog view could only be available after a write operation which changes a catalog object, so we should be able detect it during plan execution and error out. In any case, we need to verify this hypothesis and if this scenario is impossible replace the aforementioned code block with MONGO_UNREACHABLE_TASSERT.



 Comments   
Comment by Anton Korshunov [ 08/Feb/22 ]

Sounds good to me, we will look at it if we have some spare time towards the end of the project.

Comment by David Storch [ 03/Feb/22 ]

anton.korshunov my thinking was that we'd either look into it under the umbrella of this project (even though it's not strictly part of building the SBE plan cache), or just close it if we run out of time to handle this. I don't know if it's important enough to schedule on its own. But I am open to other suggestions.

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