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

Consider every ClickHouse operation as a merge #61674

Open
nikitamikhaylov opened this issue Mar 20, 2024 · 1 comment
Open

Consider every ClickHouse operation as a merge #61674

nikitamikhaylov opened this issue Mar 20, 2024 · 1 comment

Comments

@nikitamikhaylov
Copy link
Member

Use case

To simplify the code, especially the part deletion process we can say that part deletion is a merge to an empty part which will create am empty covering part (and it would be a part of replication process).

The current solution is complicated and we still find some race-conditions. For example the one fixed recently: #61610

The flip side of this mechanism is that ClickHouse will always leave an empty part in old partitions - similar to the block_number nodes in Keeper. To overcome it we can reuse SYSTEM FORGET PARTITION query introduced in #58925

WDYT? @den-crane

@den-crane
Copy link
Contributor

den-crane commented Mar 21, 2024

I don't foresee problems if SYSTEM FORGET PARTITION will be implemented.

I am NOT sure how it will impact users who move data to disks with prefer_not_merge, but such merges can disobey prefer_not_merge or you can eridicate prefer_not_merge.

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

No branches or pull requests

2 participants