feat(executor): Introduce QueryProfileManager
to collect query profilings
#11760
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.
I hereby agree to the terms of the CLA available at: https://databend.rs/dev/policies/cla/
Summary
Introduce a
QueryProfileManager
to collect query profilings.Each
databend-query
process has a global instance ofQueryProfileManager
. Every time we execute anEXPLAIN ANALYZE
statement, it would collect the profile information and store it in an LRU storage with fixed capacity(20 queries by default).Currently, it's implemented with volatile storage, which means if we restart the
databend-query
server, we will lose the query profiles. As soon as the format of the query profile is stable, we can store the data with persistent storage, e.g. S3.We can query the profiling data from the system table
system.query_profile
, here's an example:Future works
We can introduce an
enable_query_profiling
setting to allow it stores the profile information for all the common queries, e.g.SELECT
andINSERT .. SELECT ...
statements.It's possible to display the profile data in a graphical way in the future to help analyze queries.
And besides, we can fetch the query profile data from other nodes in the same databend cluster and aggregate them into a complete query profile for distributed queries.
Part of #4238