yyanyy commented on code in PR #18416: URL: https://github.com/apache/iceberg/pull/18416#discussion_r4265980947
########## format/spec.md: ########## @@ -295,6 +297,12 @@ For details on how to serialize a schema to JSON, see Appendix C. [1001]: <https://portal.ogc.org/files/?artifact_id=25355> "OGC Simple feature access" +##### Vector + +Every non-null `vector(E, D)` value must contain exactly D non-null elements of type E. Floating-point elements must not be `NaN`, positive infinity, or negative infinity. The vector value itself may be null when the containing field is optional. + +No type promotion to or from `vector` is defined, including changes to its element type or dimension. Lower and upper bounds are not defined for vector values. Review Comment: thanks everyone, > No sort order is defined for a vector value From some offline conversation there was a feedback that we might not need to artificially remove the sort order requirement, since vectors can in deed be sort naturally. While I don't have a concrete use case now, I'm thinking to not mention that this is not permitted to introduce unnecessary complication? > stats Updated the stats table to mention most of the stats (like upper/lower bound), apart from the most basic ones (row count, null count) do not fit for vector > identify int8/uint8 etc Following the discussion about narrower integers, I looked into how Parquet handles them. Its smallest integer physical type is INT32, while int8/uint8 are logical annotations that constrain the value range. These annotations do not themselves guarantee compact storage; the physical representation, encoding, and compression also matter. Iceberg can already represent these values as int, and an engine can inspect the Parquet annotation to discover the narrower range. However, without a corresponding Iceberg schema contract, that range is not guaranteed across files and future writes. We therefore indeed miss an opportunity for engines to consistently use smaller representations for vector elements, although individual readers could still optimize particular files. Custom table properties or column documentation might provide an engine-specific workaround, but would not establish an interoperable contract. As Ryan mentioned during the sync that many file format are currently rethinking about supporting narrower numeric types, I lean toward addressing narrower Iceberg element types in a follow-up proposal (I think during the sync we talked about potentially having Iceberg v5 to add them, after a more proper definition from file formats). Regarding statistics, I think we should distinguish a column whose existing values happen to fit int8 from a column declared to be int8. Statistics can establish the former and support optional allocation optimizations, but cannot constrain future values. Using them as a persistent width declaration would conflate those two cases and might not be ideal IMO. A standardized schema contract seems preferable, but that belongs with the broader discussion of narrower integer support. -- 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]
