rdblue commented on code in PR #14234: URL: https://github.com/apache/iceberg/pull/14234#discussion_r3197636348
########## format/spec.md: ########## @@ -683,6 +683,13 @@ Notes: 5. The `content_offset` and `content_size_in_bytes` fields are used to reference a specific blob for direct access to a deletion vector. For deletion vectors, these values are required and must exactly match the `offset` and `length` stored in the Puffin footer for the deletion vector blob. 6. The following field ids are reserved on `data_file`: 141. +###### File-level column statistics + +Per-column metrics used for filtering and planning are stored at **file** granularity on the `data_file` struct. +In v3, implementations use maps such as `value_counts`, `lower_bounds`, and `upper_bounds`, keyed by column id, with bounds serialized as binary (see note 1 under [Data File Fields](#data-file-fields)). +Iceberg v4 adds the optional `content_stats` struct, which holds the same *logical* metrics (without `column_sizes` as that was deprecated) using nested structs and typed bounds (see [Content Stats](#content-stats)). +Stats for primitive types and Geometry / Geography / Variant are supported. Stats for nested types (`struct`, `list`, `map`) are not supported. Review Comment: This statement is confusing and probably unnecessary. I think that this is trying to state that column ranges (lower/upper bounds) are tracked for primitive columns. We don't need to disallow value count and null count for nested types, although I don't think that we would encourage people to produce them. This also mixes in bounds for variant, geometry, and geography but that's the very next section. We should make sure that section still makes sense with content stats, but the point is not that bounds are supported, it is that bounds means something different: for geo types bounds are a bounding box, and for variant bounds are lower bounds for fields within the variant. But as I said, it is the next section so it doesn't need to be mentioned here. -- 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]
