dramaticlly commented on code in PR #18585: URL: https://github.com/apache/iceberg/pull/18585#discussion_r4329477154
########## format/spec.md: ########## @@ -1011,12 +1010,27 @@ For example, stats for an optional `geometry` field named `location` with field- 10_804: optional long value_count; 10_805: optional long null_value_count; 10_807: optional long total_bytes; - // tight_bounds and nan_value_count are omitted for geo types + // nan_value_count is omitted for geo types } ``` For `variant`, both bounds are unshredded `variant` that store variant field bounds by normalized JSON paths as field names. See [Bounds for Variant](#bounds-for-variant) for details on producing these bounds. +###### Stats Tightness + +Statistics are _tight_ when the bounds, `null_value_count`, and `nan_value_count` are exact for the live rows of a file: + +* `lower_bound` and `upper_bound` for fixed-width types are equal to the minimum and maximum of the live values. +* `null_value_count` and `nan_value_count` are the counts across the live rows. + +Bounds for `string` and `binary` are never tight because they may be truncated when written. Bounds for `geometry` and `geography` are a bounding box, not exact minimum and maximum values. + +`variant` bounds are stored per leaf field and are optional; a leaf field may have no bound, but any bound that is present is exact. A `variant` value is null only when the variant itself is null; a non-null variant that encodes a variant null is not counted as a null value. + +Statistics other than the bounds, `null_value_count`, and `nan_value_count` are not part of tightness. In particular, `value_count` is the number of values across all rows written to the file and is not adjusted when rows are deleted; for a field with no repeated (`list` or `map`) ancestor, the live value count is `value_count` minus the deletion vector's cardinality. + +When `tight_stats` is absent, readers must assume stats are not tight. A deletion vector does not by itself make a file's stats non-tight; `tight_stats` is the only indicator of tightness. Stats may be recomputed to restore tightness without rewriting the data file. Review Comment: I am not sure if we need to mention the DV case here > A deletion vector does not by itself make a file's stats non-tight. when `tight_stats` is set, the value present tightness of the statistics. missing value must be treated as not tight by all readers. (must or should, still debating the word on this as spec cannot really enforce the reader behavior) ########## format/spec.md: ########## @@ -1011,12 +1010,27 @@ For example, stats for an optional `geometry` field named `location` with field- 10_804: optional long value_count; 10_805: optional long null_value_count; 10_807: optional long total_bytes; - // tight_bounds and nan_value_count are omitted for geo types + // nan_value_count is omitted for geo types } ``` For `variant`, both bounds are unshredded `variant` that store variant field bounds by normalized JSON paths as field names. See [Bounds for Variant](#bounds-for-variant) for details on producing these bounds. +###### Stats Tightness + +Statistics are _tight_ when the bounds, `null_value_count`, and `nan_value_count` are exact for the live rows of a file: + +* `lower_bound` and `upper_bound` for fixed-width types are equal to the minimum and maximum of the live values. Review Comment: existing spec language seem to refer "variable length types", I think we shall pick either width or length to be consistent -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
