sql: crdb_internal.force_delete_table_data should use DeleteRange in 22.2
#85754
Assignees
Labels
A-kv-replication
Relating to Raft, consensus, and coordination.
branch-master
Failures and bugs on the master branch.
C-enhancement
Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
GA-blocker
T-sql-foundations
SQL Foundations Team (formerly SQL Schema + SQL Sessions)
Comments
ajwerner
added
the
C-enhancement
|
cc @cockroachdb/replication |
blathers-crl
bot
added
the
A-kv-replication
|
@ajwerner Is this something that SQL schema can pick up? |
|
Yes |
|
We should get this in now that we're entering stability. |
|
Opened up #86137, will see if there is any fallout. |
craig bot
pushed a commit
that referenced
this issue
Aug 16, 2022
86078: sql/stats: generate statistics forecasts r=rytaft,yuzefovich a=michae2 **sql/stats: use nil eval.Context as CompareContext when forecasting** When forecasting table statistics, we don't need a full *eval.Context. We can simply use a nil *eval.Context as a tree.CompareContext. This means we don't have to plumb an eval.Context into the stats cache. Assists: #79872 Release note: None **sql/stats: generate statistics forecasts in the stats cache** As of this commit, we now try to generate statistics forecasts for every column of every table. This happens whenever statistics are loaded into or refreshed in the stats cache. We use only the forecasts that fit the historical collected statistics very well, meaning we have high confidence in their accuracy. Fixes: #79872 Release note (performance improvement): Enable table statistics forecasts, which predict future statistics based on historical collected statistics. Forecasts help the optimizer produce better plans for queries that read data modified after the latest statistics collection. We use only the forecasts that fit the historical collected statistics very well, meaning we have high confidence in their accuracy. Forecasts can be viewed using `SHOW STATISTICS FOR TABLE ... WITH FORECAST`. **sql: show forecasted stats time in EXPLAIN** When using statistics forecasts, add the forecast time (which could be in the future) to EXPLAIN output. This both indicates that forecasts are in use, and gives us an idea of how up-to-date / ahead they are. Assists: #79872 Release note: None **sql/opt: add tests for statistics forecasts** Add a few simple testcases for usage of statistics forecasts by the optimizer. Assists: #79872 Release note: None --- Release justification: Enable feature before we get too far into stability period. 86137: sql: use DelRange with tombstone in `force_delete_table_data` r=ajwerner a=ajwerner Fixes #85754 Release justification: minor change needed to adopt MVCC bulk ops fully Release note: None 86160: colexecerror: do not annotate the context canceled error r=yuzefovich a=yuzefovich This commit makes it so that the context canceled error doesn't get annotated with an assertion failure when it doesn't have a valid PG code. This makes sure that the sentry issues don't get filed for the context canceled errors - they are expected to occur. Fixes: #82947 Release note: None Release justification: bug fix. 86164: sql: deflake TestRoleOptionsMigration15000User r=ajwerner a=RichardJCai Previously it was flakey because we always assumed the first user created had ID 100, however this is not the case due to transaction failures. Release note: None Release justification: test only 86173: opt: fix error due to unsupported comparison for partitioned secondary index r=rytaft a=rytaft This commit fixes a bug where we were attempting to find the locality of the partitions in a secondary index, but we passed the incorrect index ordinal to the function `IndexPartitionLocality`. Fixes #86168 Release justification: Category 3: Fixes for high-priority or high-severity bugs in existing functionality Release note (bug fix): Fixed a bug that existed on v22.1.0-v22.1.5, where attempting to select data from a table that had different partitioning columns used for the primary and secondary indexes could cause an error. This occured if the primary index had zone configurations applied to the index partitions with different regions for different partitions, and the secondary index had a different column type than the primary index for its partitioning column(s). Co-authored-by: Michael Erickson <[email protected]> Co-authored-by: Andrew Werner <[email protected]> Co-authored-by: Yahor Yuzefovich <[email protected]> Co-authored-by: richardjcai <[email protected]> Co-authored-by: Rebecca Taft <[email protected]>
exalate-issue-sync
bot
added
T-sql-foundations
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Relates to #70427. Maybe the system tenant should be able to issue
ClearRangeoptionally, but it's not totally clear. The secondary tenants shouldnot.Describe the solution you'd like
Change the
ClearRangecode after the version is active to useDeleteRangewith tombstones.Jira issue: CRDB-18423
Epic CRDB-2624
The text was updated successfully, but these errors were encountered: