ddl: pre-split region for partitioned table #10221
Conversation
|
PTAL @crazycs520 @winkyao @zimulala |
Codecov Report
@@ Coverage Diff @@
## master #10221 +/- ##
================================================
- Coverage 77.6681% 77.6578% -0.0103%
================================================
Files 411 411
Lines 85443 85444 +1
================================================
- Hits 66362 66354 -8
- Misses 14118 14128 +10
+ Partials 4963 4962 -1 |
tiancaiamao
force-pushed
the
partition-table-split
branch
from
c2aa40c to
edb722e
Compare
|
/run-all-tests |
ddl/table.go
Outdated
| pi := tbInfo.GetPartitionInfo() | ||
| if pi != nil { | ||
| // Max partition count is 4096, should we sample and just choose some of the partition to split? | ||
| go func(pi *model.PartitionInfo) { |
There was a problem hiding this comment.
How about not go? Since the split process can be really slow. Client could start to insert data before split complete.
There was a problem hiding this comment.
I add a session variable tidb_wait_table_split_finish to control use sync or async split. Maybe we can use it. in this PR: #10138
And because the split process can be really slow, I prefer to put the split process in ddl_api.go, not in the DDL owner to do this, otherwise sync split maybe block the DDL jobs.
There was a problem hiding this comment.
I've move the code from table.go to ddl_api.go
|
@tiancaiamao Why we are necessary to split partition for partitioned tables? will it cause too many regions in tikv? |
|
PTAL @crazycs520 @winkyao |
tiancaiamao
force-pushed
the
partition-table-split
branch
from
733367b to
f12b205
Compare
|
/run-all-tests |
What problem does this PR solve?
Reduce split region costs
What is changed and how it works?
Split region for partitioned table when creating
Check List
Tests