2010YOUY01 commented on code in PR #18644:
URL: https://github.com/apache/datafusion/pull/18644#discussion_r2544035992
##########
datafusion/physical-plan/src/aggregates/mod.rs:
##########
@@ -418,6 +504,13 @@ pub struct AggregateExec {
/// Describes how the input is ordered relative to the group by columns
input_order_mode: InputOrderMode,
cache: PlanProperties,
+ /// During initialization, if the plan supports dynamic filtering (see
[`AggrDynFilter`]),
+ /// it is set to `Some(..)` regardless of whether it can be pushed down to
a child node.
+ ///
+ /// During filter pushdown optimization, if a child node can accept this
filter,
+ /// it remains `Some(..)` to enable dynamic filtering during aggregate
execution;
+ /// otherwise, it is cleared to `None`.
Review Comment:
I don't quite get the issue yet. Do you have an example case for this
'wasted effort', like the child is replying `Yes` but it's not holding an
dynamic filter, or other situations we should better disable the dynamic filter
in the AggregateExec side.
One thing I feel also ambiguous is when a child replies, (e.g. for parquet)
do we differentiate if they're using the dynamic filter for stat pruning, or
evaluate filter row by row (what
`datafusion.execution.parquet.pushdown_filters` controls). I'm only expecting
this aggregate dynamic filter to skip pruneable units instead of doing
row-level filtering .
--
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]
