sql/opt: add implicit SELECT FOR UPDATE support for UPSERT statements

[nvanbenschoten]

Fixes #50180.

This commit adds support for implicit SELECT FOR UPDATE support for UPSERT statements with a VALUES clause. This should improve throughput and latency for contended UPSERT statements in much the same way that 435fa43 did for UPDATE statements. However, this only has an effect on UPSERT statements into tables with multiple indexes because UPSERT statements into single-index tables hit a fast-path where they perform a blind-write without doing an initial row scan.

Conceptually, if we picture an UPSERT statement as the composition of a SELECT statement and an INSERT statement (with loosened semantics around existing rows) then this change performs the following transformation:

UPSERT t = SELECT FROM t + INSERT INTO t
=>
UPSERT t = SELECT FROM t FOR UPDATE + INSERT INTO t

I plan to test this out on a contended indexes workload at some point in the future.

Release note (sql change): UPSERT statements now acquire locks using the FOR UPDATE locking mode during their initial row scan, which improves performance for contended workloads when UPSERTing into tables with multiple indexes. This behavior is configurable using the enable_implicit_select_for_update session variable and the sql.defaults.implicit_select_for_update.enabled cluster setting.

[cockroach-teamcity]

This change is 

[RaduBerinde]

Reviewable status: complete! 1 of 0 LGTMs obtained

[nvanbenschoten]

I plan to test this out on a contended indexes workload at some point in the future.

To test this, I ran a quick, unscientific experiment on my laptop. Using the indexes workload's new --cycle-length flag, I created a setup with a decent amount of contention. --concurrency was set to 32 and --cycle-length was set to 32. I then varied the number of secondary indexes while switching implicit SELECT FOR UPDATE on and off.

For --secondary-indexes=0, implicit SFU made no difference because of the fast-path discussed above. For all other cases, we see the same trends that we saw with implicit SFU for UPDATE statements. First, we see that throughput is a little over 50% higher using implicit SFU. Second, we see that tail latency is about 90% lower using implicit SFU.

Again, this was an unscientific experiment, but it makes a pretty strong claim that this change is beneficial for contended UPSERT statements.

[nvanbenschoten]

TFTR!

bors r+

[craig]

Build succeeded:

• GitHub CI (Cockroach)