marcin-krystianc commented on code in PR #242:
URL: https://github.com/apache/parquet-format/pull/242#discussion_r1613012422
##########
src/main/thrift/parquet.thrift:
##########
@@ -1165,6 +1317,62 @@ struct FileMetaData {
9: optional binary footer_signing_key_metadata
}
+/** Metadata for a column in this file. */
+struct FileColumnMetadataV3 {
+ /** All column chunks in this file (one per row group) **/
+ 1: required list<ColumnChunkV3> columns
Review Comment:
> > I think that if instead of:
> > `required list<ColumnChunkV3> columns`
> > we had another indirection
> > `required list<i64> column_chunk_offsets // n+1 offsets to ColumnChunkV3`
> > it would solve the problem of random row group access.
>
> It could also be a `required list<binary> encoded_chunks // Thrift-encoded
ColumnChunkV3 objects`. That way, you don't have to issue one additional IO for
each column chunk.
FYI: I've run a quick experiment to see the difference between
thrift-decoding of 1 million elements of different types.
According to my results, binary is about 10-15x faster than the struct and
the offset is 100x faster than the struct.
My test thrift structure was:
```
struct MyTestStructure {
1: optional list<ColumnChunk> columns_struct
2: optional list<binary> columns_binary
3: optional list<i64> column_offsets
}
```
The results are:
```
Deserialize structs: 41000006 bytes, 409ms
Deserialize binary: 42000006 bytes, 25ms
Deserialize offsets: 2991750 bytes, 4ms
```
--
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]
