[SERVER-16895] Users should be able to request that explain not bypass the plan cache Created: 16/Jan/15 Updated: 30/Jan/24 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | J Rassi | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 4 |
| Labels: | qexec-team, storch | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||||||||||||||||||
| Sprint: | Query 2020-11-30, Query 2020-12-14, Query 2020-12-28, Query 2021-01-11, Query 2021-01-25, Query Execution 2021-02-22, Query Execution 2021-03-08, Query Execution 2021-03-22, QE 2023-08-21, QE 2023-09-04, QE 2023-09-18, QE 2023-10-02, QE 2023-10-16, QE 2023-10-30 | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||
| Description |
|
Users should be able to request that explain not bypass the plan cache. This would enable users to more easily retrieve stats information about queries run against with the shape's current cached plan, to aid in introspection when diagnosing query performance issues. Users can get similar functionality today by using getPlansByQuery() to look up the currently cached plan and then requesting an explain of a hinted query against that plan. However, not all plans can be hinted (for example, multi-index plans cannot be hinted). Also, making this a 1-step process would improve usability. |
| Comments |
| Comment by Xiaochen Wu [ 08/Jun/23 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
If I'm correct, we need to decide how users will be issuing the request (not bypass plan cache) and also the output format when the explain results are from plan cache. I'd recommend us to move this to quick win candidates first and get into the voting process. Once we decide to pick it up in the next quarter, the assignee and the product can work together on a mini design doc for the syntax changes. Make sense? FYI kateryna.kamenieva@mongodb.com | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Chris Harris [ 12/Feb/21 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi david.storch, Thanks for the update and extra detail regarding the impact that Somewhat by coincidence, we do plan on attempting to leverage the plan cache information more frequently going forward than we have historically. The introduction of the $planCacheStats aggregation operator combined with the queryHash field make retrieving the data much easier than it was previously. As correctly forming the explain command is also sometimes difficult for larger expressions, it seems that gathering the information via an aggregation pipeline will provide a superior experience. The data from the plan cache also helps answer the "what happened" question (as opposed to "what is/can happen" that explain provides more broadly). Given the above, I can't immediately think of a situation where we would need explain output directly using the cached plan where the associated plan cache information itself would not suffice. Perhaps the one edge case would be the combination where debug information has been stripped and we are not able to hint the cached plan. It is probably "to be determined" how commonly this happens in practice. Perhaps that's what we can track in this ticket to help make a prioritization decision in the future. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by David Storch [ 10/Feb/21 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
christopher.harris and alex.bevilacqua, after discussing this more with kateryna.kamenieva we have decided to return this ticket to the backlog. Please let us know if you find a need for this improvement on versions that have the fix for related ticket To elaborate,
As you can see, the amount of information available from the plan cache in the case of stripped debug info is dramatically reduced. I could imagine that this could be a problem for support scenarios, e.g. if a customer is experiencing a performance problem due to a bad plan cache entry. The suggestion in this ticket relates in that it would allow the user to discover details about the cached plan using explain. By explaining a poorly performing query, and instructing explain to make use of the plan cache, the user could see details about the cached plan even when the debug info has been stripped. I'd be to discuss this more if you have any thoughts, but for now this ticket is headed back to the backlog. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by David Storch [ 13/Oct/20 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Flagging for scheduling. This came up in the context of |