sql: translate SQL increments into kv IncrementRequests

[nvanbenschoten]

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.

[petermattis]

This is moderately challenging because IncrementRequest relies on a particular format for the value which isn't usually true for SQL row data. We'd have to extend IncrementRequest to be told the format of the row and column it is incrementing.

[nvanbenschoten]

Yeah, that's a good point. We'd need to teach IncrementRequest about SQL value encoding. This would probably also only be possible if the value was in its own column family.

[bdarnell]

This would probably also only be possible if the value was in its own column family.

We could add a column identifier to the request to make it work when there are other columns in the family.

IIRC Increment currently has some issues with replays when used outside of an explicit transaction. That's fine for its current uses (allocating range/node/store ids), but we'd need to harden this for use in SQL.

Increments give us a lot of other opportunities for optimization too. Non-transactional increments to the same key can be batched. They're commutative, which we may be able to take advantage of by assigning timestamps as late as possible to minimize contention.

[nvanbenschoten]

Closing in favor of the more general #29431.