vustef commented on code in PR #2342:
URL: https://github.com/apache/iceberg-rust/pull/2342#discussion_r3107292843
##########
crates/iceberg/src/arrow/reader.rs:
##########
@@ -281,16 +282,25 @@ impl ArrowReader {
tasks
.map_ok(move |task| {
let file_io = file_io.clone();
+ let delete_file_loader =
self.delete_file_loader.clone();
+
+ async move {
+ let stream = Self::process_file_scan_task(
+ task,
+ batch_size,
+ file_io,
+ delete_file_loader,
+ row_group_filtering_enabled,
+ row_selection_enabled,
+ parquet_read_options,
+ )
+ .await?;
- Self::process_file_scan_task(
- task,
- batch_size,
- file_io,
- self.delete_file_loader.clone(),
- row_group_filtering_enabled,
- row_selection_enabled,
- parquet_read_options,
- )
+ // Spawn stream consumption onto a separate tokio
task so that
+ // CPU-heavy Parquet decompression runs on the
tokio thread pool
+ // rather than being serialized on the polling
thread.
+ Ok(Self::spawn_record_batch_stream(stream, 1))
Review Comment:
Why don't we spawn for the whole thing, i.e. around `process_file_scan_task`
too?
It's not that `process_file_scan_task` and its IO is parallel already while
parquet decoding is not. Rather, it's just that `process_file_scan_task` is
mostly IO, and for IO it's enough to have single task since it could execute
many IOs concurrently, while for CPU-heavy operations we need to spawn tasks so
that they can scale across threads.
Although I don't have any data out of the box, I believe it'd be beneficial
to be able to scale `process_file_scan_task`s across threads too.
--
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]
