You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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.
The text was updated successfully, but these errors were encountered:
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.
@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.
The text was updated successfully, but these errors were encountered: