RFC: coprocessor write #60
Conversation
Signed-off-by: Yilin Chen <[email protected]>
|
cc @breeswish @zhangjinpeng1987 @coocood @cfzjywxk @youjiali1995 |
|
|
||
| This optimization needs some more work. We can create a `PointPrewrite` executor which is a specialized `TableScan` as the bottom executor of DAG. It yields results just like `TableScan` but also does constraint checks of prewrite. After the execution, we are safe to send the mutations to the underlying raft store without checking write conflicts again. | ||
|
|
||
| ### DAG_PESSIMISTIC_LOCK |
There was a problem hiding this comment.
I think this feature doesn't have much benefit as DAG_PREWRITE.
It's only useful for UPDATE statements with primary key range condition.
There was a problem hiding this comment.
Could you clarify it a bit more? I don't see why it's limited to primary key range conditions.
If it only has a selection exectuor, I think the filtered rows are exactly the rows that need to be locked.
There was a problem hiding this comment.
But still, it's much more complicated than DAG_PREWRITE which only needs to handle the auto-commit single key non-index update.
It is unlikely to be implement in 5.0 release.
There was a problem hiding this comment.
Yes I agree it's more complicated than DAG_PREWRITE.
This document is only an RFC for technical discussion. I'm not going to decide which version will contain these features here.
I think it should be the product managers who decide it after the RFC is mostly accepted.
There was a problem hiding this comment.
How about we separate the two features into different RFCs?
|
|
||
| However, in multiple cases, we can move some of the logic from the client to TiKV to reduce one RPC and save encoding/decoding cost. | ||
|
|
||
| ### Simple updates |
There was a problem hiding this comment.
I think we could make it more detailed about what scenarios we are about to solve with this RFC, how should we extend it if we want to solve more.
|
|
||
| We can find the result set contains sufficient information to construct the row keys we want to lock. It would be better if we can use only one RPC to do the query and lock these keys. Coprocessor can take the result set of the query as the input of `AcquirePessimisticLock`. This can save one RPC. | ||
|
|
||
| ## Detailed design |
There was a problem hiding this comment.
We could add some execution flow to explain how the optimized scenarios will work. From the SQL execution perspective.
Update or pessimistic lock push-downs have been mentioned a lot of times but there are only rough ideas.
This RPC intends to make clear the protocol and how this feature will be implemented in TiKV.
Rendered