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

Workload classification for merges and mutations #63211

Open
serxa opened this issue Apr 30, 2024 · 1 comment · May be fixed by #64061
Open

Workload classification for merges and mutations #63211

serxa opened this issue Apr 30, 2024 · 1 comment · May be fixed by #64061
Assignees
Labels

Comments

@serxa
Copy link
Member

serxa commented Apr 30, 2024

There is a setting workload that allows to specify how a query should be classified for resource consumption (only IO resources at the moment). We need a way to specify the workload setting for merges and mutations.

Use case

  1. This will enable users to specify how queries and merges share IO. https://clickhouse.com/docs/en/operations/workload-scheduling#hierarchy.
  2. Setting different workload for different tables provides a way to prioritize merges of specific tables.
  3. Setting different workload for merges and mutations provides a way to prioritize one over another.

Describe the solution you'd like
Add a server and a merge tree settings merge_workload and mutation_workload.

@serxa serxa added the feature label Apr 30, 2024
@serxa
Copy link
Member Author

serxa commented May 1, 2024

Also, we should pay attention to the existing scheduler of a background thread pool. We should avoid running tasks that are blocked by the IO scheduler, but occupy a thread in the background pool, blocking other tasks. It could lead to "priority inversion" of a kind.

@serxa serxa self-assigned this May 1, 2024
@serxa serxa linked a pull request May 17, 2024 that will close this issue
31 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant