WIP: NOT READY FOR REVIEW: Add parquet progressive_io option to keep one-shot row group I/O with pushdown filters - #24395
WIP: NOT READY FOR REVIEW: Add parquet progressive_io option to keep one-shot row group I/O with pushdown filters#24395alamb wants to merge 1 commit into
progressive_io option to keep one-shot row group I/O with pushdown filters#24395Conversation
… pushdown filters Adds `datafusion.execution.parquet.progressive_io` (default `false`). When filter pushdown is enabled, the parquet decoder normally fetches data progressively: the columns for each filter predicate first, then (after the filters are evaluated) the remaining projected columns for the rows that passed. With `progressive_io = false` (the default), all column chunks a row group could need (filter and projection columns) are instead fetched with a single I/O request per row group -- the same I/O pattern used when `pushdown_filters` is disabled. Filter evaluation itself is unchanged. With `progressive_io = true`, progressive fetching is used when it could actually reduce bytes read (the file has an offset index); files without an offset index still use one request per row group. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
run benchmark clickbench_partitioned |
|
run benchmark clickbench_pushdown |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing alamb/progressive_io (4342770) to 00eba79 (merge-base) diff Run configurationrun benchmark clickbench_partitionedResults will be posted here when complete File an issue against this benchmark runner |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing alamb/progressive_io (4342770) to 00eba79 (merge-base) diff Run configurationrun benchmark clickbench_pushdownResults will be posted here when complete File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: Comparing alamb/progressive_io (4342770) to 00eba79 (merge-base) diff Run configurationrun benchmark clickbench_pushdownCPU Details (lscpu)Details
Resource Usageclickbench_pushdown — base (merge-base)
clickbench_pushdown — branch
File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: Comparing alamb/progressive_io (4342770) to 00eba79 (merge-base) diff Run configurationrun benchmark clickbench_partitionedCPU Details (lscpu)Details
Resource Usageclickbench_partitioned — base (merge-base)
clickbench_partitioned — branch
File an issue against this benchmark runner |
Which issue does this PR close?
filter_pushdown) by default #3463Note: this is a prototype and is NOT READY FOR REVIEW. It exists to evaluate whether decoupling the I/O pattern from filter pushdown avoids the I/O-related regressions that have blocked enabling
pushdown_filtersby default.Rationale for this change
Enabling
pushdown_filterstoday also changes the I/O pattern: instead of one request per row group, the reader sequentially fetches the columns for each filter predicate, then (after evaluating the filters) the remaining projected columns. When a file has no offset index (e.g. the ClickBench dataset), those extra round trips cannot prune any bytes, so they are pure overhead.This PR separates "filter evaluation mechanics" from the I/O pattern via a new config option,
datafusion.execution.parquet.progressive_io:pushdown_filtersprogressive_ioWhat changes are included in this PR?
progressive_ioconfig option (config, proto, docs,ParquetSource::with_progressive_io), resolved table-or-session likepushdown_filtersRowFilterGeneratornow exposes the union of the filter predicates'ProjectionMasksPushDecoderStreamState::transitionexpands the firstNeedsDatarequest of each row group to those ranges, so the whole row group is fetched in oneget_byte_rangescall. The decoder's buffered-range containment check then satisfies all subsequent phases with zero additional I/O. No arrow-rs changes were needed.Known prototype limitations:
Are these changes tested?
Yes:
object_store_access.rsshow that withpushdown_filters=trueand the defaultprogressive_io=false, the scan issues exactly one data request per row group with byte ranges identical to the non-pushdown scan, and thatprogressive_io=truerestores the current progressive patternAre there any user-facing changes?
Yes: a new configuration option, and (intentionally) a changed default I/O pattern for users who enable
pushdown_filters. Benchmarks (clickbench_pushdown) to follow.