sql/opt/exec: perform implicit SELECT FOR UPDATE on UPDATE with index join

[nvanbenschoten]

Fixes #45511.

This commit enables implicit row-level locking on UPDATEs with an index-join
in its initial row scan. To support this, two new patterns were needed in
Builder.shouldApplyImplicitLockingToUpdateInput:

(Update
    $input:(IndexJoin
        $input:(Scan $scanPrivate:*)
        $indexJoinPrivate:*
    )
    $checks:*
    $mutationPrivate:*
)

AND

(Update
    $input:(Project
        $input:(IndexJoin
            $input:(Scan $scanPrivate:*)
            $indexJoinPrivate:*
        )
        $projections:*
        $passthrough:*
    )
    $checks:*
    $mutationPrivate:*
)

These extra patterns are pushing the limits of this form of pattern matching,
but this is ok for the next release. If/when we want to make any more general,
we should strongly consider Andy's proposal to fold the patten matching and
analysis into the explorer rather than execbuilder.

[cockroach-teamcity]

This change is 

[RaduBerinde]

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @andy-kimball and @nvanbenschoten)

---

pkg/sql/opt/exec/execbuilder/mutation.go, line 804 at r2 (raw file):

		return false
	}

This is all a very complicated way of saying we want [Project] [IndexJoin] Scan (which is also an easier way to think about things). I would just peel off a Project if there is one, then peel off an IndexJoin if there is one, then check that we have a Scan.

[nvanbenschoten]

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @andy-kimball and @RaduBerinde)

---

pkg/sql/opt/exec/execbuilder/mutation.go, line 804 at r2 (raw file):

Previously, RaduBerinde wrote…

This is all a very complicated way of saying we want [Project] [IndexJoin] Scan (which is also an easier way to think about things). I would just peel off a Project if there is one, then peel off an IndexJoin if there is one, then check that we have a Scan.

That's a really good point. Done.

[nvanbenschoten]

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @andy-kimball and @RaduBerinde)

---

pkg/sql/opt/exec/execbuilder/mutation.go, line 804 at r2 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

That's a really good point. Done.

Out of curiosity, what would the corresponding optgen pattern look like for this expression pattern? Is there a way to express it succinctly?

[andy-kimball]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @andy-kimball, @nvanbenschoten, and @RaduBerinde)

---

pkg/sql/opt/exec/execbuilder/mutation.go, line 804 at r2 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

Out of curiosity, what would the corresponding optgen pattern look like for this expression pattern? Is there a way to express it succinctly?

optgen doesn't have support for doing nested matching like this, so in case like this, I might write a rule like:

(Update | Delete
  $input:* & (CanApplyImplicitLocking $input)
  $checks:*
  $mutationPrivate:*
)
=>
((OpName)
  (ApplyImplicitLocking $input)
  $checks
  $mutationPrivate
)

Even though we're not getting value from optgen for the matching you need to do here, we still benefit from matching the top-level operators:

1. It's nice to have all our patterns in the optgen language for readability.
2. Optgen will generate multiple instances of the rule for each mutation operator it applies to, and place in right locations in factory.
3. Optgen will generate the boilerplate code for making this work with our testing tools like optsteps and random rule suppression.

[RaduBerinde]

Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @nvanbenschoten and @RaduBerinde)

[nvanbenschoten]

TFTRs!

Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @andy-kimball and @RaduBerinde)

---

pkg/sql/opt/exec/execbuilder/mutation.go, line 804 at r2 (raw file):
Got it, thanks for expanding. The reasons for including this in optgen despite the fact that the pattern match itself will be in Go are compelling.

Optgen will generate multiple instances of the rule for each mutation operator it applies to, and place in right locations in factory.

One thing I'm not sure about is whether UPDATE and DELETE will want to match on the same patterns for their input. I think I found that they don't a few weeks ago, but I haven't returned to pulling on that thread. I'm no longer planning on pushing through implicit SFU for DELETE statements for this release because I don't know of a single workload that will benefit from them.

[andy-kimball]

---

pkg/sql/opt/exec/execbuilder/mutation.go, line 804 at r2 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

Got it, thanks for expanding. The reasons for including this in optgen despite the fact that the pattern match itself will be in Go are compelling.

Optgen will generate multiple instances of the rule for each mutation operator it applies to, and place in right locations in factory.

One thing I'm not sure about is whether UPDATE and DELETE will want to match on the same patterns for their input. I think I found that they don't a few weeks ago, but I haven't returned to pulling on that thread. I'm no longer planning on pushing through implicit SFU for DELETE statements for this release because I don't know of a single workload that will benefit from them.

That's fine. Often what I do in situations like this is just match on the union of patterns. In other words, even if we don't generate a Project op in the DELETE case (or whatever else), it doesn't hurt to match that pattern. It's simpler to just batch together Delete, Update, Upsert, etc.