You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
150866: sql: harden logging logic in an error case r=yuzefovich a=yuzefovich
We just saw a sentry report where we hit a nil pointer with `planner.curPlan.instrumentationHelper` being nil when trying to log a statement. This happened after we hit an error in `handleAOST`, so we short-circuited "dispatch to execution engine" part, meaning that the plan is left uninitialized. Previously, in eac1971 we attempted to handle such scenarios by tracking a boolean indicating whether the dispatch has occurred, but in this case we marked the boolean "true" (meaning it has occurred), yet we short-circuited due to an error.
This commit refactors how we ensure that the plan is initialized by simply checking whether the corresponding fields are set or not. In turn, this exposed the fact that we previously didn't unset `planner.curPlan` when resetting the planner, which is now fixed.
I spent some time trying to come up with a repro but didn't succeed, so there is no regression test.
Fixes: #150717.
Release note: None
151366: sql: improve stmt bundles a bit r=yuzefovich a=yuzefovich
This commit addresses two minor issues around the stmt bundles:
- previously, we would always include the value of `direct_columnar_scans_enabled` session variable even when it's not changed from the default. This was a bug where we overrode the value of `skip` boolean based on whether crdb_test build tag was set.
- it also hardens `debug sb recreate` command to ignore `cluster.preserve_downgrade_option` if it's set - it has no effect on the execution, yet it can break recreation on a new enough binary.
Epic: None
Release note: None
151429: allkeywords: replace switch with map in GetKeywordID r=yuzefovich a=yuzefovich
Long time ago in 74f630c we switched the implementation of keyword ID lookup in lexer from the map to a large generated switch. At that time it was more performant, but with the new swiss table implementation of hash maps in Go I was curious to see whether the map approach is now faster, and it turns out to be so, so this commit switches back to the map lookup.
```
name old time/op new time/op delta
Parse/simple-8 12.4µs ± 0% 12.1µs ± 0% -2.05% (p=0.000 n=8+9)
Parse/string-8 18.2µs ± 0% 18.0µs ± 0% -1.24% (p=0.000 n=10+9)
Parse/tpcc-delivery-8 25.0µs ± 0% 24.5µs ± 0% -1.73% (p=0.000 n=10+10)
Parse/account-8 32.9µs ± 0% 32.2µs ± 0% -2.14% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
Parse/simple-8 3.56kB ± 0% 3.56kB ± 0% ~ (all equal)
Parse/string-8 3.83kB ± 0% 3.83kB ± 0% ~ (all equal)
Parse/tpcc-delivery-8 6.14kB ± 0% 6.14kB ± 0% ~ (all equal)
Parse/account-8 11.2kB ± 0% 11.2kB ± 0% ~ (all equal)
name old allocs/op new allocs/op delta
Parse/simple-8 22.0 ± 0% 22.0 ± 0% ~ (all equal)
Parse/string-8 26.0 ± 0% 26.0 ± 0% ~ (all equal)
Parse/tpcc-delivery-8 41.0 ± 0% 41.0 ± 0% ~ (all equal)
Parse/account-8 75.0 ± 0% 75.0 ± 0% ~ (all equal)
```
Epic: None
Release note: None
151504: opt: fix incorrect filter elimination in join reordering r=mgartner a=mgartner
A bug in join reordering which incorrectly eliminated filters has been
fixed. The join reordering logic could sometimes eliminate filters of
the form `a=a` when constructing new inner-joins. It incorrectly assumed
these filters to be redundant because a column is always equivalent to
itself. However, `a=a` is a null-rejecting filter, so it can only be
omitted if `a` is guaranteed to be non-null by something else, like
another filter or a `NOT NULL` constraint.
There is no release note because, as far as we know, this bug is not
possible to hit in production. The only reproduction we have requires
optimization rules to be disabled, which can only happen in tests.
Fixes#146507
Release note: None
151578: rowexec: fix JoinReader benchmarks r=yuzefovich a=yuzefovich
We recently added an assertion that the lookup join with "equality columns are key" property never fetches more than one lookup row for each input row. In a couple of existing benchmarks this fact was violated, so this commit fixes the issue. Namely, previously we set it to indicate that we want cross-range parallelism, but now we actually have a separate boolean on the processor spec, which makes the fix simple.
Fixes: #151296.
Fixes: #151299.
Release note: None
151608: backup: refactor ValidateEndTimeAndTruncate r=jeffswenson a=kev-cao
This patch refactors `ValidateEndTimeAndTruncate` to zip together the slices of URIs, manifests, and locality information into a single slice. This allows for easier manipulation of the slices instead of treating them as separate identities.
Epic: None
Release note: None
151667: sqlstats: fix insights benchmark bugs r=kyle-a-wong a=dhartunian
- Transactions slice length was incorrectly initialized.
- Transactions needed to set a UUID in order to get observed by the `observeTransaction` function and actually trigger the code that's being benchmarked.
- Indexing into the `transactions` slice in the benchmark was incorrectly using `idx` instead of `i` and grabbing empty objects.
Resolves: #151300
Epic: None
Release note: None
Co-authored-by: Yahor Yuzefovich <[email protected]>
Co-authored-by: Marcus Gartner <[email protected]>
Co-authored-by: Kevin Cao <[email protected]>
Co-authored-by: David Hartunian <[email protected]>
consterrPrefix="invalid RESTORE timestamp: restoring to arbitrary time requires that BACKUP for requested time be created with 'revision_history' option."
0 commit comments