-
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/stats: store non-NULL histograms for empty tables #81793
Conversation
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.
Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: complete! 1 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.
Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @michae2)
TFTRs! bors r=msirek,rytaft |
Sigh. bors r- |
Canceled. |
We have been storing NULL histograms / using nil HistogramData for all the following cases: 1. regular stats, GenerateHistogram=false 2. regular stats, GenerateHistogram=true, empty table 3. regular stats, GenerateHistogram=true, all NULL values 4. inverted stats, no inverted index 5. inverted stats, yes inverted index, empty table 6. inverted stats, yes inverted index, all NULL values When predicting histograms for statistics forecasts, we need to distinguish between case 1 and cases 2 and 3. In case 1 we cannot predict histograms, but in cases 2 and 3 we can (and the emptiness of the histogram is important). So, for cases 2 and 3 we now store an empty histogram instead of NULL, and correspondingly use an initialized HistogramData with 0-length Buckets instead of nil HistogramData. This also helps with testing statistics forecasts. (The inability to distinguish cases 4-6 doesn't matter, because we cannot predict histograms for inverted indexes anyway. I tried to change cases 5 and 6 to be non-NULL for consistency but ran into some problems, so I'll leave them as they are.) Release note: None
Let's try this again. bors r=msirek,rytaft |
Build succeeded: |
Encountered an error creating backports. Some common things that can go wrong:
You might need to create your backport manually using the backport tool. error creating merge commit from 82b5926 to blathers/backport-release-22.1-81793: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 22.1.x failed. See errors above. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is otan. |
`PrintTableStats` is used by several variants of `EXPLAIN` to print an `ALTER TABLE INJECT STATISTICS` command with the current statistics for a given table. At least two of these variants (the existing `EXPLAIN (OPT, ENV)` and the upcoming `EXPLAIN ANALYZE (DEBUG, REDACT)`) want those statistics with histograms removed. We were removing histograms by simply deleting the `histo_buckets` JSON element, leaving behind some other histogram-related elements (`histo_col_type` and `histo_version`). As of cockroachdb#81793 the existence of these elements without `histo_buckets` indicates an empty table with an empty histogram, rather than a non-empty table without a histogram. To indicate a non-empty table without a histogram, we have to also remove `histo_version` and set `histo_col_type` to the empty string. (The difference currently only matters for statistics forecasting.) Epic: CRDB-19756 Release note: None
92719: sql: fix removal of histograms when printing table statistics r=msirek,rytaft a=michae2 `PrintTableStats` is used by several variants of `EXPLAIN` to print an `ALTER TABLE INJECT STATISTICS` command with the current statistics for a given table. At least two of these variants (the existing `EXPLAIN (OPT, ENV)` and the upcoming `EXPLAIN ANALYZE (DEBUG, REDACT)`) want those statistics with histograms removed. We were removing histograms by simply deleting the `histo_buckets` JSON element, leaving behind some other histogram-related elements (`histo_col_type` and `histo_version`). As of #81793 the existence of these elements without `histo_buckets` indicates an empty table with an empty histogram, rather than a non-empty table without a histogram. To indicate a non-empty table without a histogram, we have to also remove `histo_version` and set `histo_col_type` to the empty string. (The difference currently only matters for statistics forecasting.) Epic: CRDB-19756 Release note: None Co-authored-by: Michael Erickson <[email protected]>
We have been storing NULL histograms / using nil HistogramData for all
the following cases:
When predicting histograms for statistics forecasts, we need to
distinguish between case 1 and cases 2 and 3. In case 1 we cannot
predict histograms, but in cases 2 and 3 we can (and the emptiness of
the histogram is important).
So, for cases 2 and 3 we now store an empty histogram instead of NULL,
and correspondingly use an initialized HistogramData with 0-length
Buckets instead of nil HistogramData.
This also helps with testing statistics forecasts.
(The inability to distinguish cases 4-6 doesn't matter, because we
cannot predict histograms for inverted indexes anyway. I tried to change
cases 5 and 6 to be non-NULL for consistency but ran into some
problems, so I'll leave them as they are.)
Release note: None