Is your feature request related to a problem or challenge?
RowFilter evaluates each ArrowPredicate separately, so same-projection predicates may decode or replay the same column more than once. #10859 reuses one decoded stream and evaluates later predicates only on surviving rows.
This can avoid repeated decoding or predicate-cache replay, but fragmented or dense survivors may be expensive to materialize. Fusion can therefore regress some workloads.
Describe the solution you'd like
When consecutive predicates use the same projection, the Parquet reader should be able to evaluate them from one decoded stream. This avoids repeated decoding or predicate-cache replay while preserving predicate order and ensuring that each predicate sees only rows accepted by earlier predicates.
Fusion should not be an unconditional rewrite: as described above, materializing survivors can cost more than the repeated work it removes for some execution shapes. How to decide when fusion applies — a conservative structural rule, caller configuration, or something smarter — is left open for discussion. #10859 currently uses a conservative structural gate (a single top-level, non-repeated leaf projection, and no active row limit).
Describe alternatives you've considered
No response
Additional context
Is your feature request related to a problem or challenge?
RowFilterevaluates eachArrowPredicateseparately, so same-projection predicates may decode or replay the same column more than once. #10859 reuses one decoded stream and evaluates later predicates only on surviving rows.This can avoid repeated decoding or predicate-cache replay, but fragmented or dense survivors may be expensive to materialize. Fusion can therefore regress some workloads.
Describe the solution you'd like
When consecutive predicates use the same projection, the Parquet reader should be able to evaluate them from one decoded stream. This avoids repeated decoding or predicate-cache replay while preserving predicate order and ensuring that each predicate sees only rows accepted by earlier predicates.
Fusion should not be an unconditional rewrite: as described above, materializing survivors can cost more than the repeated work it removes for some execution shapes. How to decide when fusion applies — a conservative structural rule, caller configuration, or something smarter — is left open for discussion. #10859 currently uses a conservative structural gate (a single top-level, non-repeated leaf projection, and no active row limit).
Describe alternatives you've considered
No response
Additional context
ReadPlanBuilder::with_predicate_options#10776