[GitHub] [flink] slinkydeveloper commented on pull request #17520: [FLINK-24565][avro] Port avro file format factory to BulkReaderFormatFactory

2021-11-16 Thread GitBox
slinkydeveloper commented on pull request #17520: URL: https://github.com/apache/flink/pull/17520#issuecomment-970125850 Just did another pass, from table point of view this is good to go for me -- This is an automated message from the Apache Git Service. To respond to the message,

[GitHub] [flink] slinkydeveloper commented on pull request #17520: [FLINK-24565][avro] Port avro file format factory to BulkReaderFormatFactory

2021-10-21 Thread GitBox
slinkydeveloper commented on pull request #17520: URL: https://github.com/apache/flink/pull/17520#issuecomment-948377409 @tsreaper I start getting your point of lazyness, but now I wonder, why is Avro different from, for example parquet? In parquet format, I see that when you invoke

[GitHub] [flink] slinkydeveloper commented on pull request #17520: [FLINK-24565][avro] Port avro file format factory to BulkReaderFormatFactory

2021-10-20 Thread GitBox
slinkydeveloper commented on pull request #17520: URL: https://github.com/apache/flink/pull/17520#issuecomment-947418884 > The biggest concern is that StreamFormatAdapter.Reader#readBatch stores all results in a batch in heap memory. This is bad because avro is a format which supports