alamb commented on PR #15566: URL: https://github.com/apache/datafusion/pull/15566#issuecomment-2791020563
> It was @alamb that suggested we do it this way, unless I misunderstood his suggestion. > > I think it's possible to do the recursion as an optimizer rule but making the APIs flexible enough to handle all of the cases with joins, etc. gets very complicated especially because the recursion needs to probe and jump, transmit information back up, etc. I think my original suggestions were around trying to simplify the changes to ExecutionPlan trait. As I recall the original draft PR had at least three new methods on `ExecutionPlan` that had to be kept in sync: 1. Could the node itself handle any filters internally? 2. Could the node push filters past itself (the equivalent of what `try_swap_with_projection` does)? 3. Did the node produce any dynamic filters? By combining the operations into a single method that did all three at once the ExecutionPlan changes were much smaller. I don't remember any opinions about the recursion but I may not have made that clear -- 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
