diagnose: enhance the execdetails when the pessimistic retry happens
- Dominant language
- Go
- Stars
- 40.5k
- Forks
- 6.2k
- PR merge metrics
- PR metrics pending
Description
## Enhancement
Ref: https://github.com/pingcap/tidb/issues/34106
When pessimistic retry happens, the whole statement would be retired several times because of the write conflict error. By now the slow log would display information like this:
```
id task estRows operator info actRows execution info memory disk
Update_6 root 0 N/A 0 time:3.47s, loops:6, , lock_keys: {time:684µs, region:2, keys:2, lock_rpc:641.969µs, rpc_count:2, retry_count:1} 0 Bytes N/A
└─Selection_11 root 1.01 eq(t.c, "1") 1 time:3.47s, loops:7 11.4 KB N/A
└─Point_Get_10 root 1 table:t, clustered index:PRIMARY(pk), lock 1 time:3.47s, loops:8, Get:{num_rpc:6, total_time:1.74ms} N/A N/A
```
It's still quite unclear how the `3.47s` duration is composed of. Actually, the kv RPC seems to be quite fast. For the point get executor, the lock happens when it's executed but nothing related is recorded in the point get execution details. There're several things that could be done to improve this and make the diagnosis information clear.
- Record the information properly if the statement retry happens especially the pessimistic conflict retry path.
- Record the lock execution details in the point get and batch point get executors correctly.
Contributor guide
Assessment
This issue has not been assessed yet.