-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sql: parser and optimizer support FOR {UPDATE,SHARE} SKIP LOCKED #85720
sql: parser and optimizer support FOR {UPDATE,SHARE} SKIP LOCKED #85720
Conversation
cc0d4c7
to
4733eab
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
, though I only skimmed the second and third commit.
Reviewed 6 of 6 files at r1, 13 of 13 files at r2, 21 of 21 files at r3, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @michae2)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for picking this up! This looks great!
Reviewed 6 of 6 files at r1, 13 of 13 files at r2, 21 of 21 files at r3, all commit messages.
Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @rytaft)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't forget to update the commit messages when you squash them - if I understand correctly, SKIP LOCKED only affects:
- Pushing limits below index joins
- Optimizations that rely on multiplicity and pushing limits
Reviewed 6 of 6 files at r1, 13 of 13 files at r2, 21 of 21 files at r3, all commit messages.
Reviewable status: complete! 3 of 0 LGTMs obtained (waiting on @rytaft)
pkg/sql/logictest/testdata/logic_test/select_for_update
line 432 at r3 (raw file):
# All columns are available from the secondary index on u, so no index join is # needed.
nit: It might be helpful to spell out that the secondary index (and lack of index join) can produce the row where k=2 instead of skipping it.
pkg/sql/opt/table_meta.go
line 148 at r3 (raw file):
// of this table (i.e. rules that assume there is always a PK row for every // secondary index row or a FK row for every FK reference). IsSkipLocked bool
It's regrettable that we need this bool in addition to the locking struct in ScanPrivate. But I see how it allows checkIsSkipLocked
to avoid traversing the entire right subexpression. I don't see any way around it though, and I can't think of a better place to track this.
I initially thought that it could be better to include the set of skip-locked columns in relational properties - but I'm not so sure anymore. For one thing, that'd require more computation and space.
pkg/sql/opt/memo/multiplicity_builder.go
line 92 at r3 (raw file):
// If no rows are being removed from the table, add all its columns. No rows // are removed from a table if this is an un-limited, unconstrained scan // over a non-partial index.
nit: update this comment
pkg/sql/opt/memo/multiplicity_builder.go
line 263 at r3 (raw file):
func filtersMatchAllLeftRows(left, right RelExpr, filters FiltersExpr) bool { if checkIsSkipLocked(right.Memo().Metadata(), right) { return false
nit: You could add unit tests for this in multiplicity_builder_test.go
.
pkg/sql/opt/xform/groupby_funcs.go
line 416 at r3 (raw file):
// Otherwise, try to construct an IndexJoin operator that provides the // columns missing from the index. if sp.Flags.NoIndexJoin {
We should probably have tests for all these rules where we were forgetting to check NoIndexJoin
, what do you think? You can do it in a follow-up PR if that's easier.
pkg/sql/opt/xform/index_scan_builder.go
line 167 at r3 (raw file):
func (b *indexScanBuilder) AddIndexJoin(cols opt.ColSet) { if b.scanPrivate.Flags.NoIndexJoin { panic(errors.AssertionFailedf("attempt to create an index join with NoIndexJoin flag"))
nit: you could also add this in check_expr
since there is at least one rule where an index join is created without using this function.
Should we mark this as fixing #40476? |
Now that KV support this, we can pass the wait policy through. Fixes cockroachdb#40476 Release note (sql change): SELECT ... FOR {UPDATE,SHARE} SKIP LOCKED is now supported. The option can be used to skip rows that cannot be immediately locked instead of blocking on contended row-level lock acquisition.
e70cf81
to
5653ae0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TFTRs!
Don't forget to update the commit messages when you squash them
Done.
Should we mark this as fixing #40476?
Done 🥳
Reviewable status: complete! 1 of 0 LGTMs obtained (and 2 stale) (waiting on @mgartner, @michae2, and @nvanbenschoten)
pkg/sql/logictest/testdata/logic_test/select_for_update
line 432 at r3 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
nit: It might be helpful to spell out that the secondary index (and lack of index join) can produce the row where k=2 instead of skipping it.
Done.
pkg/sql/opt/table_meta.go
line 148 at r3 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
It's regrettable that we need this bool in addition to the locking struct in ScanPrivate. But I see how it allows
checkIsSkipLocked
to avoid traversing the entire right subexpression. I don't see any way around it though, and I can't think of a better place to track this.I initially thought that it could be better to include the set of skip-locked columns in relational properties - but I'm not so sure anymore. For one thing, that'd require more computation and space.
Yea... I didn't see a better option either.
pkg/sql/opt/memo/multiplicity_builder.go
line 92 at r3 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
nit: update this comment
Done.
pkg/sql/opt/memo/multiplicity_builder.go
line 263 at r3 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
nit: You could add unit tests for this in
multiplicity_builder_test.go
.
Done.
pkg/sql/opt/xform/groupby_funcs.go
line 416 at r3 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
We should probably have tests for all these rules where we were forgetting to check
NoIndexJoin
, what do you think? You can do it in a follow-up PR if that's easier.
Yea, I split this out and will do it (including tests) in a follow-up PR.
pkg/sql/opt/xform/index_scan_builder.go
line 167 at r3 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
nit: you could also add this in
check_expr
since there is at least one rule where an index join is created without using this function.
Will add in a follow-up PR
bors r+ |
Build failed (retrying...): |
bors r- It looks like |
Canceled. |
For queries using SELECT FOR {SHARE,UPDATE} SKIP LOCKED, we need to disable optimizations that depend on preserved-multiplicity consistency of tables. When SKIP LOCKED is used, we will no longer use optimizations that assume: - a PK row exists for every secondary index row - a PK row exists for every referencing FK (if the PK table uses SKIP LOCKED) One result of this change is that we will no longer push limits into index joins if the primary index uses locking wait policy SKIP LOCKED. This commit also disallows use of multiple column families in tables scanned with SKIP LOCKED, since it could result in returning partial rows. Release note: None Co-authored-by: Michael Erickson <[email protected]>
5653ae0
to
bfbaf64
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks - fixed. I was looking at the wrong build I guess.
Reviewable status: complete! 1 of 0 LGTMs obtained (and 2 stale) (waiting on @mgartner, @michae2, and @nvanbenschoten)
pkg/sql/opt/xform/groupby_funcs.go
line 416 at r3 (raw file):
Previously, rytaft (Rebecca Taft) wrote…
Yea, I split this out and will do it (including tests) in a follow-up PR.
bors r+ |
Build failed (retrying...): |
Build succeeded: |
`TableMeta.IsSkipLocked` was used by the multiplicity builder to determine whether a column was filtered or not by a `SKIP LOCKED` scan. However, this field was unnecessary. The `deriveUnfilteredCols` function in the multiplicity builder already traverses expressions all the way down to `ScanExpr`s, only collecting unfiltered columns if they originate from a scan where `ScanExpr.IsUnfiltered` returns true. `ScanExpr.IsUnfiltered` returns false if the scan is a `SKIP LOCKED` scan. Therefore, no additional mechanism is required to detect columns filtered by `SKIP LOCKED` scans. I noticed that `TableMeta.IsSkipLocked` was not needed because the multiplicity builder unit tests added in cockroachdb#85720 never set it, yet the tests passed. This commit also adds more multiplicity builder unit tests for self-joins with `SKIP LOCKED`. Release note: None
85735: streamingccl: multi-node unit tests r=samiskin a=samiskin None of our tests used to run with multiple nodes and a scattered table, so this PR re-enables the unavailable node test and creates a new basic multinode test. It also fixes a bug where if the stream creation statement was retried, it would now error on an existing tenant, since the tenant creation wasn't associated with the overall transaction. Release note: None 85739: kvserver: simplify and track entire set of gossiped IOThresholds r=erikgrinaker a=tbg This commit makes the following changes: - track *all* IOThresholds in the store's map, not just the ones for overloaded stores. - improve the container for these IOThresholds to be easier to work with. - Rather than "hard-coding" a value of "1.0" to mean overloaded, use (and plumb) the value of the cluster setting. "1.0" is the value at which I/O admission control chooses to engage; but the cluster setting is usually smaller and determines when to consider followers on a remote store pausable. The API now reflects that and avoids this kind of confusion. - Rename all uses of the container away from "overload" towards "IOThreshold". - add a Sequence() method that is bumped whenever the set of Stores whose IOThreshold score indicates pausability changes. I originally started to work on this to address #84465, but realized that we couldn't "just" leave the set of paused followers untouched absent sequence changes. This is because the set of paused followers has additional inputs, most importantly the set of live followers. This set is per-Replica and subject to change, so we can't be too sure the outcome would be the same, and we do want to be reactive to followers becoming nonresponsive by, if necessary, unpausing followers. I think we will have to address #84465 by reducing the frequency at which the paused stores are revisited, but adding an eager pass whenever the sequence is bumped. Additionally, for #84252, we are likely also going to be able to rely on the sequence number to trigger unquiescing of ranges that were previously quiesced in the presence of a paused follower. Regardless of these future possible uses, this is a nice conceptual clean-up and a good last PR to land for pausing in the 22.2 cycle (unless we find time to add quiescence in presence of paused followers, in which case that would be worthy follow-up). I verified that with this commit, the [roachtest] still works and effectively avoids I/O admission control activation a large percentage of the time at a setting of 0.8. This gives good confidence - at least for this exact test - that with 0.5 we'd probably never see admission control throttle foreground writes. However, the test is fairly specific since it severely constrains n3's disk throughput, so 0.8 might be perfectly appropriate in practice still. We'll need some more experience to tell. [roachtest]: #81516 Touches #84465. Touches #84252. Release note: None Release justification: low-risk improvement to new functionality 85933: opt: remove TableMeta.IsSkipLocked r=rytaft a=mgartner #### opt: fix duplicate join multiplicity test Test case 9 in `TestGetJoinMultiplicity` was a duplicate of test case 2. It has been updated to be similar, but use an `INNER JOIN` instead of a `LEFT JOIN`, which I believe it was originally supposed to be - there is no similar existing test case. Release note: None #### opt: remove TableMeta.IsSkipLocked `TableMeta.IsSkipLocked` was used by the multiplicity builder to determine whether a column was filtered or not by a `SKIP LOCKED` scan. However, this field was unnecessary. The `deriveUnfilteredCols` function in the multiplicity builder already traverses expressions all the way down to `ScanExpr`s, only collecting unfiltered columns if they originate from a scan where `ScanExpr.IsUnfiltered` returns true. `ScanExpr.IsUnfiltered` returns false if the scan is a `SKIP LOCKED` scan. Therefore, no additional mechanism is required to detect columns filtered by `SKIP LOCKED` scans. I noticed that `TableMeta.IsSkipLocked` was not needed because the multiplicity builder unit tests added in #85720 never set it, yet the tests passed. This commit also adds more multiplicity builder unit tests for self-joins with `SKIP LOCKED`. Release note: None #### opt: ensure min cardinality of zero for expressions with SKIP LOCKED This commit ensures that the minimum cardinality of a scan or lookup-join with `SKIP LOCKED` is zero. This shouldn't be needed because the logical to derive the cardinality for these expressions should never produce a non-zero minimum cardinality, but this provides extra safety. Release note: None #### opt: improve comments in multiplicity builder Release note: None 86053: util: optimize FastIntSet r=rytaft a=mgartner This PR contains several commits which speed up `util.FastIntSet` and reduce the allocations it makes in some cases. See the individual commit messages for details. The speedup and reduction in allocations can be observed in the optimizer's `BenchmarkPhases`: ``` name old time/op new time/op delta kv-read/Simple/OptBuildNorm-16 34.9µs ± 2% 35.0µs ± 4% ~ (p=1.000 n=5+5) kv-read/Simple/Explore-16 43.9µs ± 2% 43.7µs ± 1% ~ (p=0.222 n=5+5) kv-read/Prepared/ExecBuild-16 1.18µs ± 1% 1.13µs ± 1% -3.72% (p=0.008 n=5+5) kv-read-const/Simple/OptBuildNorm-16 35.2µs ± 2% 34.9µs ± 3% ~ (p=0.151 n=5+5) kv-read-const/Simple/Explore-16 45.2µs ± 5% 44.3µs ± 1% ~ (p=0.056 n=5+5) kv-read-const/Prepared/ExecBuild-16 1.02µs ± 4% 0.97µs ± 1% -5.18% (p=0.008 n=5+5) tpcc-new-order/Simple/OptBuildNorm-16 71.1µs ± 1% 70.8µs ± 0% ~ (p=0.548 n=5+5) tpcc-new-order/Simple/Explore-16 117µs ± 1% 116µs ± 2% ~ (p=0.095 n=5+5) tpcc-new-order/Prepared/ExecBuild-16 1.48µs ± 2% 1.44µs ± 1% -2.67% (p=0.008 n=5+5) tpcc-delivery/Simple/OptBuildNorm-16 65.5µs ± 2% 63.9µs ± 1% -2.37% (p=0.032 n=5+4) tpcc-delivery/Simple/Explore-16 96.2µs ± 1% 95.7µs ± 1% ~ (p=0.690 n=5+5) tpcc-delivery/Prepared/AssignPlaceholdersNorm-16 12.5µs ± 1% 12.3µs ± 1% ~ (p=0.095 n=5+5) tpcc-delivery/Prepared/Explore-16 40.5µs ± 1% 39.4µs ± 0% -2.75% (p=0.008 n=5+5) tpcc-stock-level/Simple/OptBuildNorm-16 291µs ± 2% 288µs ± 2% ~ (p=0.310 n=5+5) tpcc-stock-level/Simple/Explore-16 424µs ± 0% 417µs ± 2% -1.79% (p=0.016 n=5+5) tpcc-stock-level/Prepared/AssignPlaceholdersNorm-16 53.8µs ± 0% 53.3µs ± 1% ~ (p=0.151 n=5+5) tpcc-stock-level/Prepared/Explore-16 181µs ± 2% 176µs ± 3% -2.44% (p=0.032 n=5+5) many-columns-and-indexes-a/Simple/OptBuildNorm-16 309µs ± 0% 254µs ± 2% -17.78% (p=0.008 n=5+5) many-columns-and-indexes-a/Simple/Explore-16 467µs ± 1% 389µs ± 1% -16.65% (p=0.008 n=5+5) many-columns-and-indexes-a/Prepared/AssignPlaceholdersNorm-16 275µs ± 1% 223µs ± 1% -18.93% (p=0.008 n=5+5) many-columns-and-indexes-a/Prepared/Explore-16 434µs ± 2% 358µs ± 1% -17.68% (p=0.008 n=5+5) many-columns-and-indexes-b/Simple/OptBuildNorm-16 331µs ± 1% 281µs ± 2% -14.91% (p=0.008 n=5+5) many-columns-and-indexes-b/Simple/Explore-16 500µs ± 2% 424µs ± 1% -15.23% (p=0.008 n=5+5) many-columns-and-indexes-b/Prepared/AssignPlaceholdersNorm-16 279µs ± 1% 228µs ± 1% -17.98% (p=0.008 n=5+5) many-columns-and-indexes-b/Prepared/Explore-16 449µs ± 5% 367µs ± 0% -18.20% (p=0.008 n=5+5) many-columns-and-indexes-c/Simple/OptBuildNorm-16 13.7ms ± 1% 10.6ms ± 1% -22.68% (p=0.008 n=5+5) many-columns-and-indexes-c/Simple/Explore-16 45.7ms ± 2% 40.0ms ± 2% -12.42% (p=0.008 n=5+5) many-columns-and-indexes-c/Prepared/AssignPlaceholdersNorm-16 11.1ms ± 1% 8.6ms ± 2% -22.77% (p=0.008 n=5+5) many-columns-and-indexes-c/Prepared/Explore-16 43.3ms ± 0% 37.8ms ± 2% -12.65% (p=0.008 n=5+5) ored-preds-100/Simple/OptBuildNorm-16 2.59ms ± 1% 2.60ms ± 1% ~ (p=0.690 n=5+5) ored-preds-100/Simple/Explore-16 3.29ms ± 3% 3.31ms ± 2% ~ (p=0.548 n=5+5) ored-preds-100/Prepared/ExecBuild-16 85.5µs ± 1% 84.7µs ± 1% ~ (p=0.095 n=5+5) ored-preds-using-params-100/Simple/OptBuildNorm-16 1.88ms ± 1% 1.88ms ± 1% ~ (p=0.421 n=5+5) ored-preds-using-params-100/Simple/Explore-16 2.56ms ± 1% 2.57ms ± 1% ~ (p=0.413 n=4+5) ored-preds-using-params-100/Prepared/AssignPlaceholdersNorm-16 468µs ± 3% 472µs ± 2% ~ (p=0.421 n=5+5) ored-preds-using-params-100/Prepared/Explore-16 1.16ms ± 1% 1.17ms ± 1% ~ (p=0.222 n=5+5) name old alloc/op new alloc/op delta kv-read/Simple/OptBuildNorm-16 12.3kB ± 0% 12.3kB ± 0% ~ (all equal) kv-read/Simple/Explore-16 14.7kB ± 0% 14.7kB ± 0% ~ (all equal) kv-read/Prepared/ExecBuild-16 704B ± 0% 704B ± 0% ~ (all equal) kv-read-const/Simple/OptBuildNorm-16 12.4kB ± 0% 12.4kB ± 0% ~ (all equal) kv-read-const/Simple/Explore-16 14.8kB ± 0% 14.8kB ± 0% ~ (all equal) kv-read-const/Prepared/ExecBuild-16 520B ± 0% 520B ± 0% ~ (all equal) tpcc-new-order/Simple/OptBuildNorm-16 24.0kB ± 0% 24.0kB ± 0% ~ (p=0.881 n=5+5) tpcc-new-order/Simple/Explore-16 34.0kB ± 0% 33.9kB ± 0% -0.01% (p=0.032 n=5+5) tpcc-new-order/Prepared/ExecBuild-16 768B ± 0% 768B ± 0% ~ (all equal) tpcc-delivery/Simple/OptBuildNorm-16 19.8kB ± 0% 19.8kB ± 0% ~ (p=0.722 n=5+5) tpcc-delivery/Simple/Explore-16 26.3kB ± 0% 26.3kB ± 0% ~ (p=0.802 n=5+5) tpcc-delivery/Prepared/AssignPlaceholdersNorm-16 5.44kB ± 0% 5.44kB ± 0% ~ (all equal) tpcc-delivery/Prepared/Explore-16 13.1kB ± 0% 13.1kB ± 0% ~ (p=1.000 n=5+5) tpcc-stock-level/Simple/OptBuildNorm-16 89.8kB ± 0% 89.8kB ± 0% ~ (p=0.817 n=5+5) tpcc-stock-level/Simple/Explore-16 120kB ± 0% 120kB ± 0% ~ (p=0.937 n=5+5) tpcc-stock-level/Prepared/AssignPlaceholdersNorm-16 18.8kB ± 0% 18.8kB ± 0% ~ (p=1.000 n=5+5) tpcc-stock-level/Prepared/Explore-16 46.9kB ± 0% 46.9kB ± 0% ~ (p=0.262 n=5+5) many-columns-and-indexes-a/Simple/OptBuildNorm-16 16.4kB ± 0% 16.4kB ± 0% ~ (all equal) many-columns-and-indexes-a/Simple/Explore-16 23.1kB ± 0% 23.1kB ± 0% ~ (p=1.000 n=5+5) many-columns-and-indexes-a/Prepared/AssignPlaceholdersNorm-16 3.81kB ± 0% 3.81kB ± 0% ~ (all equal) many-columns-and-indexes-a/Prepared/Explore-16 10.5kB ± 0% 10.5kB ± 0% ~ (p=1.000 n=5+5) many-columns-and-indexes-b/Simple/OptBuildNorm-16 23.6kB ± 0% 23.6kB ± 0% ~ (p=0.730 n=5+5) many-columns-and-indexes-b/Simple/Explore-16 30.0kB ± 0% 30.0kB ± 0% ~ (p=0.159 n=5+5) many-columns-and-indexes-b/Prepared/AssignPlaceholdersNorm-16 6.05kB ± 0% 6.05kB ± 0% ~ (p=1.000 n=5+5) many-columns-and-indexes-b/Prepared/Explore-16 12.4kB ± 0% 12.4kB ± 0% ~ (p=0.540 n=5+5) many-columns-and-indexes-c/Simple/OptBuildNorm-16 5.43MB ± 0% 4.75MB ± 0% -12.49% (p=0.008 n=5+5) many-columns-and-indexes-c/Simple/Explore-16 27.0MB ± 0% 26.3MB ± 0% -2.58% (p=0.008 n=5+5) many-columns-and-indexes-c/Prepared/AssignPlaceholdersNorm-16 4.27MB ± 0% 3.65MB ± 0% -14.54% (p=0.008 n=5+5) many-columns-and-indexes-c/Prepared/Explore-16 25.8MB ± 0% 25.2MB ± 0% -2.48% (p=0.008 n=5+5) ored-preds-100/Simple/OptBuildNorm-16 979kB ± 0% 979kB ± 0% ~ (p=0.889 n=5+5) ored-preds-100/Simple/Explore-16 1.37MB ± 0% 1.37MB ± 0% ~ (p=0.690 n=5+5) ored-preds-100/Prepared/ExecBuild-16 29.6kB ± 0% 29.6kB ± 0% ~ (all equal) ored-preds-using-params-100/Simple/OptBuildNorm-16 568kB ± 0% 568kB ± 0% ~ (p=0.794 n=5+5) ored-preds-using-params-100/Simple/Explore-16 962kB ± 0% 962kB ± 0% ~ (p=0.841 n=5+5) ored-preds-using-params-100/Prepared/AssignPlaceholdersNorm-16 348kB ± 0% 348kB ± 0% ~ (p=0.548 n=5+5) ored-preds-using-params-100/Prepared/Explore-16 742kB ± 0% 742kB ± 0% ~ (p=0.841 n=5+5) name old allocs/op new allocs/op delta kv-read/Simple/OptBuildNorm-16 77.0 ± 0% 77.0 ± 0% ~ (all equal) kv-read/Simple/Explore-16 88.0 ± 0% 88.0 ± 0% ~ (all equal) kv-read/Prepared/ExecBuild-16 9.00 ± 0% 9.00 ± 0% ~ (all equal) kv-read-const/Simple/OptBuildNorm-16 79.0 ± 0% 79.0 ± 0% ~ (all equal) kv-read-const/Simple/Explore-16 90.0 ± 0% 90.0 ± 0% ~ (all equal) kv-read-const/Prepared/ExecBuild-16 6.00 ± 0% 6.00 ± 0% ~ (all equal) tpcc-new-order/Simple/OptBuildNorm-16 128 ± 0% 128 ± 0% ~ (all equal) tpcc-new-order/Simple/Explore-16 171 ± 0% 171 ± 0% ~ (all equal) tpcc-new-order/Prepared/ExecBuild-16 9.00 ± 0% 9.00 ± 0% ~ (all equal) tpcc-delivery/Simple/OptBuildNorm-16 120 ± 0% 120 ± 0% ~ (all equal) tpcc-delivery/Simple/Explore-16 169 ± 0% 169 ± 0% ~ (all equal) tpcc-delivery/Prepared/AssignPlaceholdersNorm-16 27.0 ± 0% 27.0 ± 0% ~ (all equal) tpcc-delivery/Prepared/Explore-16 77.0 ± 0% 77.0 ± 0% ~ (all equal) tpcc-stock-level/Simple/OptBuildNorm-16 552 ± 0% 552 ± 0% ~ (all equal) tpcc-stock-level/Simple/Explore-16 711 ± 0% 711 ± 0% ~ (all equal) tpcc-stock-level/Prepared/AssignPlaceholdersNorm-16 105 ± 0% 105 ± 0% ~ (all equal) tpcc-stock-level/Prepared/Explore-16 264 ± 0% 264 ± 0% ~ (all equal) many-columns-and-indexes-a/Simple/OptBuildNorm-16 69.0 ± 0% 69.0 ± 0% ~ (all equal) many-columns-and-indexes-a/Simple/Explore-16 89.0 ± 0% 89.0 ± 0% ~ (all equal) many-columns-and-indexes-a/Prepared/AssignPlaceholdersNorm-16 21.0 ± 0% 21.0 ± 0% ~ (all equal) many-columns-and-indexes-a/Prepared/Explore-16 41.0 ± 0% 41.0 ± 0% ~ (all equal) many-columns-and-indexes-b/Simple/OptBuildNorm-16 128 ± 0% 128 ± 0% ~ (all equal) many-columns-and-indexes-b/Simple/Explore-16 145 ± 0% 146 ± 0% ~ (p=0.167 n=5+5) many-columns-and-indexes-b/Prepared/AssignPlaceholdersNorm-16 36.0 ± 0% 36.0 ± 0% ~ (all equal) many-columns-and-indexes-b/Prepared/Explore-16 53.0 ± 0% 53.0 ± 0% ~ (all equal) many-columns-and-indexes-c/Simple/OptBuildNorm-16 72.3k ± 0% 61.7k ± 0% -14.66% (p=0.029 n=4+4) many-columns-and-indexes-c/Simple/Explore-16 295k ± 0% 284k ± 0% -3.68% (p=0.008 n=5+5) many-columns-and-indexes-c/Prepared/AssignPlaceholdersNorm-16 66.1k ± 0% 56.4k ± 0% -14.69% (p=0.008 n=5+5) many-columns-and-indexes-c/Prepared/Explore-16 289k ± 0% 279k ± 0% -3.46% (p=0.008 n=5+5) ored-preds-100/Simple/OptBuildNorm-16 16.5k ± 0% 16.5k ± 0% ~ (p=0.333 n=5+4) ored-preds-100/Simple/Explore-16 17.9k ± 0% 17.9k ± 0% ~ (all equal) ored-preds-100/Prepared/ExecBuild-16 413 ± 0% 413 ± 0% ~ (all equal) ored-preds-using-params-100/Simple/OptBuildNorm-16 4.08k ± 0% 4.08k ± 0% ~ (all equal) ored-preds-using-params-100/Simple/Explore-16 5.54k ± 0% 5.54k ± 0% ~ (all equal) ored-preds-using-params-100/Prepared/AssignPlaceholdersNorm-16 1.44k ± 0% 1.44k ± 0% ~ (all equal) ored-preds-using-params-100/Prepared/Explore-16 2.89k ± 0% 2.89k ± 0% ~ (all equal) ``` Co-authored-by: Shiranka Miskin <[email protected]> Co-authored-by: Tobias Grieger <[email protected]> Co-authored-by: Marcus Gartner <[email protected]>
This PR adds support for
SKIP LOCKED
by building on commits from #83627 and #82188. See below for details.sql: enable the skip-locked wait policy
Now that KV support this, we can pass the wait policy through.
Fixes #40476
Release note (sql change):
SELECT ... FOR {UPDATE,SHARE} SKIP LOCKED
is now supported. The option can be used to skip rows that cannot be
immediately locked instead of blocking on contended row-level lock
acquisition.
opt: optimizer updates for support of SKIP LOCKED
For queries using
SELECT FOR {SHARE,UPDATE} SKIP LOCKED
, we need to disableoptimizations that depend on preserved-multiplicity consistency of
tables. When
SKIP LOCKED
is used, we will no longer use optimizations thatassume:
SKIP LOCKED
)One result of this change is that we will no longer push limits into index
joins if the primary index uses locking wait policy
SKIP LOCKED
.This commit also disallows use of multiple column families in tables scanned
with
SKIP LOCKED
, since it could result in returning partial rows.Release note: None
Co-authored-by: Michael Erickson [email protected]