Uh oh!
There was an error while loading. Please reload this page.
[spark] Cover the zero a truncation reports surviving a later ANALYZE - #9350
Closed
sundapeng wants to merge 1 commit into
Closed
[spark] Cover the zero a truncation reports surviving a later ANALYZE#9350sundapeng wants to merge 1 commit into
sundapeng wants to merge 1 commit into
Conversation
A truncation reports an exact zero for the partitions it emptied. ANALYZE measures a partition and writes what it found. Nothing pinned what the second does to the first, and the failure would be silent in the direction that matters: a zero degraded back to unknown reads as "nobody measured this", so a planner that guards on the value being known starts skipping the partition instead of knowing it is empty. The case truncates a measured partition and then runs both forms of ANALYZE over it, asserting the zero is still a zero. It needs `TRUNCATE TABLE` and `ANALYZE TABLE` together, which is why it could not go in with either of them.
sundapeng
marked this pull request as draft
August 22, 2026 02:17
sundapeng
marked this pull request as ready for review
August 22, 2026 02:17
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
A truncation reports an exact zero for every partition it emptied.
ANALYZEmeasures a partitionand writes down what it found. Nothing pinned what the second does to the first.
The failure would be silent in the direction that matters. Statistics carry
UNKNOWNas a negativevalue, so a zero degraded back to unknown does not read as "this partition is empty" but as "nobody
measured it", and a consumer that guards on the value being known skips the partition instead of
planning for an empty one. An exact zero is a measurement; it should not be reachable to lose it by
measuring again.
Tests
CatalogManagedPartitionAnalyzeTest: measure a partition, truncate it, then runCOMPUTE STATISTICS NOSCANand a fullCOMPUTE STATISTICSover it, asserting the row count and file count are stillzero rather than unknown.
The case needs
TRUNCATE TABLE(#9330) andANALYZE TABLE(#9298) in the same tree, which is whyit could not ride along with either of them. Both are in
masternow.API and Format
No production change; test only.