jayshrivastava commented on code in PR #24018:
URL: https://github.com/apache/datafusion/pull/24018#discussion_r3686973334
##########
datafusion/core/tests/physical_optimizer/filter_pushdown.rs:
##########
@@ -3085,6 +3085,111 @@ async fn test_filter_with_projection_pushdown() {
assert_batches_eq!(expected, &result);
}
+/// Test that ExecutionPlan::apply_expressions() can discover dynamic filters
across the plan tree.
+///
+/// Not portable to sqllogictest: asserts by walking the plan tree with
+/// `apply_expressions` + `downcast_ref::<DynamicFilterPhysicalExpr>` and
+/// counting nodes. Neither API is observable from SQL.
+#[tokio::test]
+async fn test_discover_dynamic_filters_via_expressions_api() {
Review Comment:
This test explicitly covers that dynamic filters are discoverable
post-pushdown. This is what we want in datafusion-distributed and I assume
other projects want this as well
##########
datafusion/physical-plan/src/aggregates/mod.rs:
##########
@@ -2506,6 +2545,8 @@ impl AggregateExec {
})?;
aggregate.with_dynamic_filter_expr(dynamic_filter)?
} else {
+ let mut aggregate = aggregate;
+ aggregate.dynamic_filter = None;
Review Comment:
Semi-related. I think this was a bug. We kept the default dynamic filter
created by `try_new` around even there's no pushed down filter. Now, we
explicitly remove it. The test I added in
`datafusion/proto/tests/cases/roundtrip_physical_plan.rs` covers this.
--
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]
