aihuaxu commented on PR #14297: URL: https://github.com/apache/iceberg/pull/14297#issuecomment-3730380694
> This PR caught my eye, as I've implemented the equivalent in DuckDB: [duckdb/duckdb#19336](https://github.com/duckdb/duckdb/pull/19336) > > The PR description doesn't give much away, but I think the approach is similar to the proposed (interim) solution here: buffer the first rowgroup, infer the shredded schema from this, then finalize the file schema and start writing data. That is correct. > > We've opted to create a `typed_value` even though the type isn't 100% consistent within the buffered data, as long as it's the most common. I think you're losing potential compression by not doing that. I'm still trying to improve the heuristics to use the most common one as shredding type rather than the first one and probably cap the number of shredded fields, etc. but it doesn't need 100% consistent type to be shredded. > > We've also added a copy option to force the shredded schema, for debugging purposes and for power users. Yeah. I think that makes sense for advanced user to determine the shredded schema since they may know the read pattern. > > As for DECIMAL, it's kind of a special case in the shredding inference. We only shred on a DECIMAL type if _all_ the decimal values we've seen for a column/field have the same width+scale, if any decimal value differs, DECIMAL won't be considered anymore when determining the shredded type of the column/field Why is DECIMAL special here? If we determine DECIMAL4 to be shredded type, then we may shred as DECIMAL4 or not shred if they cannot fit in DECIMAL4, right? -- 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]
