opt, sql: parallelize uniqueness checks when possible

[rytaft]

Currently, uniqueness checks are run after a mutation completes, as a series of post-queries (similar to foreign key checks). We could reduce latency by parallelizing all of these checks. It may also be possible to run the uniqueness checks in parallel with the mutation itself. If the mutation only affects a single row, the uniqueness check can be trivially parallelized with the mutation (particularly if the mutation is an INSERT with VALUES input). If it affects multiple rows, it may or may not be possible to parallelize. This is also relevant for enabling the insert fast path with uniqueness checks, as described in #58047.

cc @nvanbenschoten @andreimatei

Epic CRDB-26292

Jira issue: CRDB-3356

[yuzefovich]

Just randomly stumbled on this issue, and I think #96123 fixes it, should we close it?

[rytaft]

Yea I think so! Although what do you think about the additional suggestion for running the checks in parallel with the mutation itself in some cases?

[yuzefovich]

That seems like a good idea although orthogonal to work we did in #96123. My intuition says that in the general case parallelizing the mutation and the postquery checks is not possible, but implementing some kind of fastpath for uniqueness checks when mutating a single row would be nice. Perhaps it deserves a separate issue? Or rephrasing this issue to be specifically about that?

[rytaft]

There's already #58047 which covers the fast path, I'll just add a note there and close this.

[rytaft]

Done, closing this.