*: add table option: wait_split_finish #293
Conversation
|
I read pingcap/tidb#10138 - I am curious why don't we pre-split regions by default synchronously, is it for backward compatibility or the use case that a user needs to create a lot of tables? It becomes hard for usability if there are three options the user needs to remember:
I like the names you have chosen though, they make sense to me. |
|
@morgo , Because scatter region maybe spend a lot of time，in my local test, I have 1 TiDB, 1 PD, 3 TiKV, then pre-split 8 regions will spend 30 ~ 75s, so we hope client can control this. There are 3 options, but you can only use the related options that you need. |
| @@ -218,6 +218,9 @@ type TableInfo struct { | |||
| // The pre-split region num is 2^(PreSplitRegions-1). | |||
| // And the PreSplitRegions should less than or equal to ShardRowIDBits. | |||
| PreSplitRegions uint64 `json:"pre_split_regions"` | |||
| // WaitSplitFinish specify the pre-split region to do with synchronous or asynchronous. | |||
| // false means pre-split region with asynchronous. | |||
| WaitSplitFinish bool `json:"wait_split_finish"` | |||
There was a problem hiding this comment.
We can put this option as a session variable, it is weird to be a table option. And we should not add this field in the tableInfo.
There was a problem hiding this comment.
ok, I will use session variable to control this
What problem does this PR solve?
Add a table option
wait_split_finish.This is for PR pingcap/tidb#10138.
wait_split_finishmeans wait pre-split and scatter finish before return client.What is changed and how it works?
Check List
Tests
Code changes