berkaysynnada commented on code in PR #15770:
URL: https://github.com/apache/datafusion/pull/15770#discussion_r2052311257
##########
datafusion/physical-optimizer/src/push_down_filter.rs:
##########
@@ -382,7 +383,7 @@ impl PhysicalOptimizerRule for PushdownFilter {
context
.transform_up(|node| {
- if node.plan.as_any().downcast_ref::<FilterExec>().is_some() {
+ if node.plan.as_any().downcast_ref::<FilterExec>().is_some()
|| node.plan.as_any().downcast_ref::<SortExec>().is_some() {
Review Comment:
Yes, you're right. We can run this pushdown logic on every operator
actually, but then it will work in worst-time complexity always. I've shared
the solution of removing revisit parameter, and let me open an issue for that.
I strongly believe it will be taken and implemented in short time by some
people.
To remove these downcasts, I think we can either introduce a new method to
the API just returning a boolean saying that "this operator might introduce a
filter or not", or try to understand that by the existing API's, maybe with
some refactor. Do you have an idea for the latter?
--
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
