-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
Design of CONVERT PARTITION #56749
base: master
Are you sure you want to change the base?
Design of CONVERT PARTITION #56749
Conversation
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @mjonss. Thanks for your PR. PRs from untrusted users cannot be marked as trusted with I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
But currently the `EXCHANGE PARTITION` implementation in TiDB allows for concurrent read and write to both the exchanged table and partition, making it complex to support Global Index, where there will need to be a DDL state where one session, S1, sees the new t2 (original p) and the new p (original t2), while another session, S2, might see the original t2 and the original p. Meaning that S2 still needs to double write/update the Global Index of t, when writing to t2 and the S1 also needs to duble write/update the "local" index of t2 when writing to t/p, to keep both table's indexes consistent in the different views of S1 and S2. This makes the DDL extra complex and risky to implement and hard to test. | ||
Having a way to only allow access to the data of both t/p and t2 through table t during the DDL operation would make it less complex, fewer error handling conditions and also having less performance impact, due to less indexes to keep updated at the same time. | ||
|
||
So the question is if we should extend the syntax for `EXCHANGE PARTITION` for this new restriction and support Global Index or have a new syntax? |
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.
Maybe let exchange partition
same as MySQL and only supports the feature MySQL had.
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.
How do you propose to handle the 'swap partition and non-partitioned table' use case, what syntax should be used?
Co-authored-by: Hangjie Mo <mohangjie1995@gmail.com>
[FORMAT CHECKER NOTIFICATION] Notice: To remove the 📖 For more info, you can check the "Contribute Code" section in the development guide. |
What problem does this PR solve?
Issue Number: ref #45133
Problem Summary:
What changed and how does it work?
Check List
Tests
Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.