-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add query planning CPU time stat #15318
Conversation
Seems a system connector test is failing. Will fix. |
@sopel39 Can you confirm where we want to expose this stat? I think this stat is too detailed for |
b321fe9
to
9797f96
Compare
Added item in |
@sopel39 Hi, can you take a look? Thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm % I think you should extract mysql event listener changes to separate (follow-up) PR
@@ -131,6 +131,7 @@ public void queryCompleted(QueryCompletedEvent event) | |||
stats.getResourceWaitingTime().map(Duration::toMillis).orElse(0L), | |||
stats.getAnalysisTime().map(Duration::toMillis).orElse(0L), | |||
stats.getPlanningTime().map(Duration::toMillis).orElse(0L), | |||
stats.getPlanningCpuTime().map(Duration::toMillis).orElse(0L), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extract event listener changes to separate commit (maybe separate PR). I'm not sure if the changes here are not breaking changes for people who already setup mysql event listener.
@arhimondr could you take a look?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is braking. Though the MySQL listener is not designed to be used in production as of today and is built for testing purposes only. We don't have to maintain strong compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. In that case I thin MySQL listener should be out of scope of this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sopel39 @arhimondr
Thanks for the review. I'd like to finish this PR. I will
- Rebase w.r.t the latest commit
- Extract the changes on
trino-mysql-event-listener
to a separate PR
@@ -131,6 +131,7 @@ public void queryCompleted(QueryCompletedEvent event) | |||
stats.getResourceWaitingTime().map(Duration::toMillis).orElse(0L), | |||
stats.getAnalysisTime().map(Duration::toMillis).orElse(0L), | |||
stats.getPlanningTime().map(Duration::toMillis).orElse(0L), | |||
stats.getPlanningCpuTime().map(Duration::toMillis).orElse(0L), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is braking. Though the MySQL listener is not designed to be used in production as of today and is built for testing purposes only. We don't have to maintain strong compatibility.
71efc3e
to
9f7efe0
Compare
I've rebased and extracted the changes on |
9f7efe0
to
c025060
Compare
Could you make the build pass? |
101e80e
to
72cad60
Compare
For all CI tasks to pass I will need to include the changes on mysql event listener. Having a separate commit for the mysql event listener part will also fail since the CI validates the build success at every commit. I've updated.
Can I wait for all tests to pass then exclude the MYSQL listener part from this PR? |
I'm not sure why. You can have extra field in |
Thanks let me try that. |
72cad60
to
a8ae88b
Compare
a8ae88b
to
97fa11b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm % comment
97fa11b
to
8e07c78
Compare
merged, thanks! |
Description
This PR aims to close #2579
I think the thread in which planning begins does not need to be tracked when writing to
QueryStateTimer#planningCpuTime
. For DDL queries the whole state transitioning happens on the same thread. For normal queriesbeginPlanning
andbeginStarting
are supposed to run on the same thread in a linear fashion, hence the first attempt to setplanningCpuTime
should yield correct result.The following image shows the change on the UI. I suppose this should also be in
QueryCompletedEvent
so I will work on that and update this PR.(x) This is not user-visible or docs only and no release notes are required.
( ) Release notes are required, please propose a release note for me.
( ) Release notes are required, with the following suggested text: