stevenzwu commented on code in PR #18585:
URL: https://github.com/apache/iceberg/pull/18585#discussion_r4340444450
##########
format/spec.md:
##########
@@ -1008,15 +1007,30 @@ For example, stats for an optional `geometry` field
named `location` with field-
10_816: optional double z;
10_817: optional double m;
}
- 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
+ 10_803: optional long value_count;
+ 10_804: optional long null_value_count;
+ 10_806: optional long total_bytes;
+ // 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-length 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, and each present bound follows the rules above for its type. 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.
Review Comment:
> 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.
This sentence defines what `null_value_count` includes, so it doesn't belong
in the tightness section. If we want to clarify it, it fits with the
`null_value_count` definition in [Field-level Metrics and
Statistics](https://iceberg.apache.org/spec/#field-level-metrics-and-statistics),
next to [Bounds for
Variant](https://iceberg.apache.org/spec/#bounds-for-variant).
##########
format/spec.md:
##########
@@ -1008,15 +1007,30 @@ For example, stats for an optional `geometry` field
named `location` with field-
10_816: optional double z;
10_817: optional double m;
}
- 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
+ 10_803: optional long value_count;
+ 10_804: optional long null_value_count;
+ 10_806: optional long total_bytes;
+ // 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-length 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.
Review Comment:
> Regardless of `tight_stats` value, bounds for `string` and `binary` are
never tight because they may be truncated when written.
It might be a bit more clear by adding the qualifying phrase: "Regardless of
`tight_stats` value, ".
> Bounds for `geometry` and `geography` are a bounding box, not exact
minimum and maximum values.
The bounds section already defines these as bounding boxes. What does
`tight_stats` require for `geometry` and `geography` bounds? Are they tight
when the bounding box is computed exactly from the live rows, or are they never
tight like `string` and `binary` bounds? Could we state that explicitly?
##########
format/spec.md:
##########
@@ -1008,15 +1007,30 @@ For example, stats for an optional `geometry` field
named `location` with field-
10_816: optional double z;
10_817: optional double m;
}
- 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
+ 10_803: optional long value_count;
+ 10_804: optional long null_value_count;
+ 10_806: optional long total_bytes;
+ // 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-length 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, and each present bound follows the rules above for its type. 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.
Review Comment:
> `variant` bounds are stored per leaf field and are optional; a leaf field
may have no bound, and each present bound follows the rules above for its type.
I found it hard to understand, mainly because `leaf field` is not a defined
term in the spec. Would the rephrasing below read a bit more clearly?
> For `variant`, `lower_bound` and `upper_bound` hold one bound per
normalized JSON path. A path may be omitted, which means that path has no
bound. Whether a present bound is tight follows the same rules as above for
that path's value type.
--
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]
