feat: allow EXPLAIN on multi-statement SQL beginning with SET #20106
+58
−1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
jasonmp85
force-pushed
the
fix-explain-with-set
branch
2 times, most recently
from
431c4d2 to
4dabdf0
Compare
eric-weaver
reviewed
Apr 21, 2025
justiniso
requested changes
Apr 21, 2025
jasonmp85
force-pushed
the
fix-explain-with-set
branch
from
4dabdf0 to
77d7577
Compare
SQL strings containing multiple statements cause problems with the ex- isting explain logic. This change adds a regex to strip an arbitrary number of `SET` commands from the head of all incoming SQL, such that the eventual `EXPLAIN` will be performed on just the trailing SQL. This doesn't fully address all multi-statement SQL strings: in part- icular clients might send e.g. both a SELECT and an UPDATE in the same string. As before, this would be passed as-is to the EXPLAIN machinery. Refs: DBMON-2626
jasonmp85
force-pushed
the
fix-explain-with-set
branch
from
77d7577 to
f37b43b
Compare
lu-zhengda
reviewed
Apr 22, 2025
There was a problem hiding this comment.
Trim leading SET statement would make it pass _can_explain_statement. Can you add an integration test to make sure explain will work with multi statements?
If it's not feasible to do it with integration test and you tested it manually, can you add a screenshot instead?
| @@ -748,6 +748,8 @@ def _run_and_track_explain(self, dbname, statement, obfuscated_statement, query_ | |||
|
|
|||
| @tracked_method(agent_check_getter=agent_check_getter) | |||
| def _run_explain_safe(self, dbname, statement, obfuscated_statement, query_signature): | |||
| obfuscated_statement = trim_leading_set_stmts(obfuscated_statement) | |||
There was a problem hiding this comment.
Can we consider only run trim_leading_set_stmts if the obfuscated_statement starts with SET?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
SQL strings containing multiple statements cause problems with the existing explain logic. This change adds a regex to strip an arbitrary number of
SETcommands from the head of all incoming SQL, such that the eventualEXPLAINwill be performed on just the trailing SQL.This doesn't fully address all multi-statement SQL strings: in particular, clients might send e.g. both a SELECT and an UPDATE in the same string. As before, this would be passed as-is to the EXPLAIN machinery.
Motivation
DBMON-2626
Review checklist (to be filled by reviewers)
qa/skip-qalabel if the PR doesn't need to be tested during QA.backport/<branch-name>label to the PR and it will automatically open a backport PR once this one is merged