ozankabak commented on PR #15566:
URL: https://github.com/apache/datafusion/pull/15566#issuecomment-2793101507
> Maybe it is possible to move the recursion into the optimizer rule but
still keep a `ExecutionPlan` method by making a complex call signature, maybe
something like this:
>
> ```rust
> struct FilterPushdownArgs {
> // expressions
> filters: Vec<Arc<dyn PhysicalExprs>>
> }
>
> /// return from trying to push the filters down
> struct FilterPushdownResult {
> // filters that could potentially be pushed down to each child
> child_filters: Vec<Vec<Arc<dyn PhysicalExprs>>,
> // filters that could not be handled by this node internally
> remaining_filters: Vec<Arc<dyn PhysicalExprs>>
> // new_self
> new_self: Arc<dyn ExecutionPlan>
> }
>
> impl ExecutionPlan {
> fn try_pushdown_filters(&self, args: FilterPushdownArgs) ->
Result<FilterPushdownResult> {
> ..
> }
> }
> ```
This sort of thing is exactly what I had in mind. This enables us to do a
clean separation between the API and the rule. @berkaysynnada and I discussed
this in detail and we will circle back with a write-up including a more-fleshed
out version of this.
We will get this over the finish line in a few days. Thanks for the awesome
collaboration.
--
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: github-unsubscr...@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org
For additional commands, e-mail: github-h...@datafusion.apache.org
