In 23.2 we added a new implementation of SELECT FOR UPDATE, which is initially used only for Read Committed isolation (and Serializable isolation when optimizer_use_lock_op_for_serializable is true). As of #116170 this implementation of SELECT FOR UPDATE locks all column families of selected rows.
Separate column families are often used to reduce accidental contention. Locking all column families in SFU is simple and easy to understand, but might prevent separate column families from being an effective solution for accidental contention. It would be nice to give users control over exactly which column families are locked by SELECT FOR UPDATE.
In #116170 we tried using the projection list to pick which column families to lock, but ran into cases like SELECT 1 FROM foo FOR UPDATE or SELECT a + b FROM foo FOR UPDATE. I think a more intentional syntax like SELECT 1 FROM foo FOR UPDATE OF foo (a, b) would be easier to understand, though it would require application changes to take advantage of.
Jira issue: CRDB-34804
Epic CRDB-38938
In 23.2 we added a new implementation of SELECT FOR UPDATE, which is initially used only for Read Committed isolation (and Serializable isolation when
optimizer_use_lock_op_for_serializableis true). As of #116170 this implementation of SELECT FOR UPDATE locks all column families of selected rows.Separate column families are often used to reduce accidental contention. Locking all column families in SFU is simple and easy to understand, but might prevent separate column families from being an effective solution for accidental contention. It would be nice to give users control over exactly which column families are locked by SELECT FOR UPDATE.
In #116170 we tried using the projection list to pick which column families to lock, but ran into cases like
SELECT 1 FROM foo FOR UPDATEorSELECT a + b FROM foo FOR UPDATE. I think a more intentional syntax likeSELECT 1 FROM foo FOR UPDATE OF foo (a, b)would be easier to understand, though it would require application changes to take advantage of.Jira issue: CRDB-34804
Epic CRDB-38938