sql/opt/exec: perform implicit SELECT FOR UPDATE on UPDATE with index join#45733
sql/opt/exec: perform implicit SELECT FOR UPDATE on UPDATE with index join#45733nvb merged 1 commit intocockroachdb:masterfrom
Conversation
|
This change is |
15712e7 to
350b436
Compare
RaduBerinde
left a comment
There was a problem hiding this comment.
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.
… join Fixes cockroachdb#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.
350b436 to
8c000de
Compare
nvb
left a comment
There was a problem hiding this comment.
Reviewable status:
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.
nvb
left a comment
There was a problem hiding this comment.
Reviewable status:
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
left a comment
There was a problem hiding this comment.
Reviewable status:
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:
- It's nice to have all our patterns in the optgen language for readability.
- Optgen will generate multiple instances of the rule for each mutation operator it applies to, and place in right locations in factory.
- Optgen will generate the boilerplate code for making this work with our testing tools like
optstepsand random rule suppression.
RaduBerinde
left a comment
There was a problem hiding this comment.
Reviewable status:
nvb
left a comment
There was a problem hiding this comment.
TFTRs!
Reviewable status:
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.
|
pkg/sql/opt/exec/execbuilder/mutation.go, line 804 at r2 (raw file): Previously, nvanbenschoten (Nathan VanBenschoten) wrote…
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 |
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: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.