Skip to content
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

Merged
merged 1 commit into from
Apr 20, 2023

Conversation

weijiii
Copy link
Member

@weijiii weijiii commented Dec 6, 2022

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 queries beginPlanning and beginStarting are supposed to run on the same thread in a linear fashion, hence the first attempt to set planningCpuTime 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.

Screenshot 2023-04-01 at 3 35 18 AM

(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:

@cla-bot cla-bot bot added the cla-signed label Dec 6, 2022
@weijiii weijiii marked this pull request as ready for review December 6, 2022 22:58
@github-actions github-actions bot added the ui Web UI label Dec 6, 2022
@weijiii weijiii requested a review from sopel39 December 7, 2022 00:23
@weijiii
Copy link
Member Author

weijiii commented Dec 7, 2022

Seems a system connector test is failing. Will fix.

@weijiii
Copy link
Member Author

weijiii commented Dec 7, 2022

@sopel39 Can you confirm where we want to expose this stat? I think this stat is too detailed for runtime.query table. QueryCompletedEvent seems to be the right place. Thank you.

@weijiii weijiii force-pushed the expose_planning_cpu_stats branch from b321fe9 to 9797f96 Compare December 7, 2022 04:06
@weijiii
Copy link
Member Author

weijiii commented Dec 7, 2022

Added item in trino-spi/pom.xml because number of parameters changed for QueryStatistics

@weijiii
Copy link
Member Author

weijiii commented Dec 10, 2022

@sopel39 Hi, can you take a look? Thanks.

Copy link
Member

@sopel39 sopel39 left a 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),
Copy link
Member

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?

Copy link
Contributor

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.

Copy link
Member

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

Copy link
Member Author

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),
Copy link
Contributor

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.

@weijiii weijiii force-pushed the expose_planning_cpu_stats branch 3 times, most recently from 71efc3e to 9f7efe0 Compare April 1, 2023 09:09
@weijiii
Copy link
Member Author

weijiii commented Apr 1, 2023

I've rebased and extracted the changes on trino-mysql-event-listener to #16841
The failures are caused by the missing parts for trino-mysql-event-listener. Please take a look. Thanks!
cc: @sopel39 @arhimondr

@weijiii weijiii force-pushed the expose_planning_cpu_stats branch from 9f7efe0 to c025060 Compare April 2, 2023 01:09
@sopel39
Copy link
Member

sopel39 commented Apr 3, 2023

The failures are caused by the missing parts for trino-mysql-event-listener

Could you make the build pass?

@weijiii weijiii force-pushed the expose_planning_cpu_stats branch 3 times, most recently from 101e80e to 72cad60 Compare April 3, 2023 19:59
@weijiii
Copy link
Member Author

weijiii commented Apr 3, 2023

The failures are caused by the missing parts for trino-mysql-event-listener

Could you make the build pass?

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.

In that case I thin MySQL listener should be out of scope of this PR

Can I wait for all tests to pass then exclude the MYSQL listener part from this PR?

@sopel39
Copy link
Member

sopel39 commented Apr 14, 2023

For all CI tasks to pass I will need to include the changes on mysql event listener.

I'm not sure why. You can have extra field in QueryStatistics, but not necessarily mysql changes as part of this PR. The UI change on it's own is very useful

@weijiii
Copy link
Member Author

weijiii commented Apr 14, 2023

For all CI tasks to pass I will need to include the changes on mysql event listener.

I'm not sure why. You can have extra field in QueryStatistics, but not necessarily mysql changes as part of this PR. The UI change on it's own is very useful

Thanks let me try that.

@weijiii weijiii force-pushed the expose_planning_cpu_stats branch from 72cad60 to a8ae88b Compare April 15, 2023 05:08
@weijiii
Copy link
Member Author

weijiii commented Apr 15, 2023

@sopel39 Rebased and excluded trino-mysql-event-listener DAO. Also updated #16841 based on this PR. Thanks.

@weijiii weijiii force-pushed the expose_planning_cpu_stats branch from a8ae88b to 97fa11b Compare April 15, 2023 17:43
Copy link
Member

@sopel39 sopel39 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm % comment

@weijiii weijiii force-pushed the expose_planning_cpu_stats branch from 97fa11b to 8e07c78 Compare April 18, 2023 20:11
@sopel39 sopel39 merged commit a524709 into trinodb:master Apr 20, 2023
@sopel39 sopel39 mentioned this pull request Apr 20, 2023
@sopel39
Copy link
Member

sopel39 commented Apr 20, 2023

merged, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

Expose planningCpu time in QueryStats
3 participants