[Enhancement] Reduce lock time of schema change in scenarios with a large number of columns (backport #52800) #52842
+89
−4
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.
Why I'm doing:
This
check compatible
has a complexity of N^2. In a scenario with many columns (>10000), it will be very slow, causing the table lock to be held for a long time and the import will be stuck.What I'm doing:
Using hash map to replace the link list.
For a table with 20,000 columns, the lock holding time can be optimized from 12s to 0.8s.
TODO: 0.8s is not reasonable. There is still some optimization points and continuous optimization is needed.
What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist:
Bugfix cherry-pick branch check:
This is an automatic backport of pull request #52800 done by [Mergify](https://mergify.com). ## Why I'm doing:
This
check compatible
has a complexity of N^2. In a scenario with many columns (>10000), it will be very slow, causing the table lock to be held for a long time and the import will be stuck.What I'm doing:
Using hash map to replace the link list.
For a table with 20,000 columns, the lock holding time can be optimized from 12s to 0.8s.
TODO: 0.8s is not reasonable. There is still some optimization points and continuous optimization is needed.
What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist: