berkaysynnada commented on PR #15566: URL: https://github.com/apache/datafusion/pull/15566#issuecomment-2812469566
Current Status: 1) Having 2 parameters for plans seems very strange. On the other hand, removing it forces us to make deep copies. However, when I look the copied structs, it doesn't seem to have big deal as it's done only one time. Perhaps we can figure out a way avoiding those 2 defects at the same time (via another trait, or another API's). I'm open to discuss this 2) I've renamed retry as revisit. Of curse it'll be better to remove it now if we can find a better way, but that will be automatically resolved once TreenodeRecursion supports revisit mechanism. There are a few other places it's needed and having some workarounds like this. 3) I'm currently on this: > Do you agree that we should go on with the plan emerging after FilterPushdown rule works only if the Filter's are joining the sources? If a Filter cannot join the source and stop at any intermediate point, then we don't accept that pushed down version and keep the original plan? Related with that, I've one question: Let's say you have a plan like A(root)<- B <- C <- D <- E <- F <- G (scan). Assume E is an operator making some filtering, and F is another operator which does not allow filter push down. So, E cannot be pushed down over F. Knowing all these, can we say that all other operators(A,B,C or D --possibly having some filters) cannot also be pushed down over F? Is it a safe assumption to make? -- 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
