kv: remove V22_2 gates and related logic/migrations/etc #96765
Comments
celiala
added
C-cleanup
2 tasks
craig bot
pushed a commit
that referenced
this issue
Aug 5, 2023
105477: sql: add plan gist matching to stmt diagnostics feature r=yuzefovich a=yuzefovich This commit extends the stmt diagnostics feature to add optional plan-gist-based matching. Previously, we filtered statements based only on the fingerprint but now we can optionally ask for a particular plan (by specifying the target plan gist). All other aspects of the feature (minimum execution latency, sampling probability) are unaffected. The caveat to the implementation is that the plan gist of the running statement is available after the optimizer has done its part, so whenever plan-gist-based matching is desired, the trace will not include the optimizer part as well as the plan string won't be available. This commit also made a minor change to always store the memo and the opt planning catalog in `planTop`. Previously, this was stored only when the bundle collection is enabled, but we now can enable it after the optimizer, at which point the memo and the catalog might be lost. The optimizer now stores it unconditionally, but then if we choose to not collect the bundle once the plan gist is available, we release these things. This allows us to still get `opt` files in the bundle. Epic: None Addresses: #96765. Addresses: #103018. Release note (sql change): Statement diagnostics feature has been extended to support collecting a bundle for a particular plan. Namely, the existing fingerprint-based matching has been extended to also include plan-gist-based matching. Such bundle will miss a couple of things: `plan.txt` file as well as the tracing of the optimizer. At the moment, the feature is only exposed via an overload to `crdb_internal.request_statement_bundle` builtin function. We now also support "anti-match" - i.e. collecting a bundle for any plan other than the provided plan gist. 108139: sql: fix logic to collect stats on system.jobs r=rytaft a=rytaft This commit fixes an oversight in #102637 which intended to enable stats collection on the jobs table, but was not successful. I've manually confirmed that stats are now collected on the jobs table in a local cluster: ``` 888074673664065537 | AUTO CREATE STATS | Table statistics refresh for system.public.jobs | CREATE STATISTICS __auto__ FROM [15] WITH OPTIONS THROTTLING 0.9 AS OF SYSTEM TIME '-30s' | root | succeeded | NULL | 2023-08-03 19:01:22.343 ``` Informs #107405 Release note (performance improvement): We now automatically collect table statistics on the `system.jobs` table, which will enable the optimizer to produce better query plans for internal queries that access the `system.jobs` table. This may result in better performance of the system. Note: a previous attempt to enable stats on `system.jobs` starting in 23.1.0 was unsuccessful, but we have now fixed the oversight. Co-authored-by: Yahor Yuzefovich <yahor@cockroachlabs.com> Co-authored-by: Rebecca Taft <becca@cockroachlabs.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Now that we've bumped minBinary to 22.2[1], we should now remove all V22_2* version gates and related gated logic/migrations/etc as applicable.
V22_2 gates for Transactions & Distribution(KV)[2]:
TestSampledStmtDiagReqsMigration[1] #95530
[2] Using git blame from https://github.com/cockroachdb/cockroach/blame/984c24b05bfe3c04ffd7bec5784d475796504522/pkg/clusterversion/cockroach_versions.go
The text was updated successfully, but these errors were encountered: