aokolnychyi commented on code in PR #7105: URL: https://github.com/apache/iceberg/pull/7105#discussion_r1332171774
########## format/spec.md: ########## @@ -702,6 +703,58 @@ Blob metadata is a struct with the following fields: | _optional_ | _optional_ | **`properties`** | `map<string, string>` | Additional properties associated with the statistic. Subset of Blob properties in the Puffin file. | +#### Partition statistics + +Partition statistics files are based on [Partition Statistics file spec](#partition-statistics-file). +Partition statistics are not required for reading or planning and readers may ignore them. +Each table snapshot may be associated with at most one partition statistic file. +A writer can optionally write the partition statistics file during each write operation, and +it must be registered in the table metadata file to be considered as a valid statistics file for the reader. + +`partition-statistics` field of table metadata is an optional list of struct with the following fields: + +| v1 | v2 | Field name | Type | Description | +|----|----|------------|------|-------------| +| _required_ | _required_ | **`snapshot-id`** | `long` | ID of the Iceberg table's snapshot the partition statistics file is associated with. | +| _required_ | _required_ | **`statistics-file-path`** | `string` | Path of the partition statistics file. See [Partition Statistics file](#partition-statistics-file). | +| _required_ | _required_ | **`file-size-in-bytes`** | `long` | Size of the partition statistics file. | + +#### Partition Statistics file + +Statistics information for each unique partition tuple is stored as a row in the default data file format of the table (for example, Parquet or ORC). +These rows must be sorted (in ascending manner with NULL FIRST) by `partition` field to optimize filtering rows while scanning. + +The schema of the partition statistics file is as follows: + +| v1 | v2 | Field id, name | Type | Description | +|----|----|----------------|------|-------------| +| _required_ | _required_ | **`1 partition`** | `struct<..>` | Partition data tuple, schema based on the unified partition type considering all specs in a table | +| _required_ | _required_ | **`2 spec_id`** | `int` | Partition spec id | Review Comment: I think the spec ID is required to reconstruct the actual partition tuple, if needed. The main question is whether it is easier to work with a unified tuple or a spec-specific tuple. If most use cases need a spec-specific tuple and would require a projection, nothing prevents us from having a file per spec and annotating each partition stats file with a spec ID instead of persisting it for each record. Can we think through our initial plans for writing and reading these files? Doesn't have to be very elaborate at this point. -- 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]
