When performing an UPDATE we usually split it into two phases: a read phase and a write phase. During the read phase, we gather all rows necessary to perform the update using kv scans. During the write phase, we then send kv puts to perform the actual update.

These two distinct phases are usually necessary but could be optimized for SQL queries like:

UPDATE t SET v = v + 1

or

UPDATE t SET v = v +10 RETURNING v

Here, we could rely on our kv increment primitive (roachpb.IncrementRequests) to avoid a separate read phase. This is important because we often see these kinds of increments on hotly contested keys, as is the case in TPCC. In these situations, we should do whatever we can to avoid contention which may result in transaction restarts. Speeding up the increment would help alleviate this issue. More importantly, reducing this to a single kv operation would allow these UPDATEs to use 1PC transaction commits if they are performed in isolation, which would avoid it completely.