Sync of PD timestamps and timestamps computed when resolving a lock for parallel commit
Closed this issue · 5 comments
@MyonKeminta believes there will be problems if and only if the computed ts is > PD's latest ts + 1. I'm not clear on the concrete problems this causes or if/how they can be mitigated.
This is not a problem if we only use timestamps from PD as read ts, but might be a problem due to conflict_for_update_ts.
A simple workaround is recording whether a timestamp is allocated from PD or calculated. We can limit deriving a timestamp from a calculated timestamp.
In other words, if conflict_for_update_ts is a calculated timestamp, TiDB gets a new timestamp from PD and retry reading.
However, if the workload is to update the same key frequently, up to half of transactions need to get timestamps from PD, which makes performance a bit worse.
@sticnarf I think we do not have any other better solution. We can adopt this solution for now, and in the scenario you said maybe it's better to disable parallel commit.
Agree.
This is currently not a bug in the implementation, but is something we should bear in mind for future optimisations.