mingmwang commented on code in PR #3855:
URL: https://github.com/apache/arrow-datafusion/pull/3855#discussion_r998957711


##########
datafusion/physical-expr/src/utils.rs:
##########
@@ -0,0 +1,117 @@
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+
+//! Collection of utility functions for Physical Expr optimization
+
+use crate::PhysicalExpr;
+use datafusion_common::DataFusionError;
+use std::result;
+use std::sync::Arc;
+
+pub type Result<T> = result::Result<T, DataFusionError>;
+
+/// Apply transform `F` to the PhysicalExpr's children, the transform `F` 
might have a direction(Preorder or Postorder)
+fn map_children<F>(
+    expr: Arc<dyn PhysicalExpr>,
+    transform: F,
+) -> Result<Arc<dyn PhysicalExpr>>
+where
+    F: Fn(Arc<dyn PhysicalExpr>) -> Result<Arc<dyn PhysicalExpr>>,
+{
+    if !expr.children().is_empty() {
+        let new_children: Result<Vec<_>> =
+            expr.children().into_iter().map(transform).collect();
+        with_new_children_if_necessary(expr, new_children?)
+    } else {
+        Ok(expr)
+    }
+}
+
+/// Convenience utils for writing optimizers rule: recursively apply the given 
`op` to the PhysicalExpr tree.
+/// When `op` does not apply to a given expr, it is left unchanged.
+/// The default tree traversal direction is transform_down(Preorder Traversal).
+pub fn transform<F>(expr: Arc<dyn PhysicalExpr>, op: &F) -> Result<Arc<dyn 
PhysicalExpr>>
+where
+    F: Fn(Arc<dyn PhysicalExpr>) -> Option<Arc<dyn PhysicalExpr>>,
+{
+    transform_down(expr, op)
+}
+
+/// Convenience utils for writing optimizers rule: recursively apply the given 
'op' to the PhysicalExpr and all of its

Review Comment:
   I think the tree visit pattern is common among rules,  either post order or 
pre order. So we do not need to implement a visitor again and again, the only 
difference is when the rule try to do the tree travese, the mutation behavior 
is different. So we can have a common tree visitor pattern and pass the 
different behavior as a Closure. It will make writing optimization rule much 
more straightforward and more FP programming.
   
   For example, I rewrite the `CoalesceBatches` rule, use the new utils:
   ````
   impl PhysicalOptimizerRule for CoalesceBatches {
       fn optimize(
           &self,
           plan: Arc<dyn crate::physical_plan::ExecutionPlan>,
           _config: &crate::execution::context::SessionConfig,
       ) -> Result<Arc<dyn crate::physical_plan::ExecutionPlan>> {
           let target_batch_size = self.target_batch_size;
           transform_up(plan, &|plan| {
               let plan_any = plan.as_any();
               let wrap_in_coalesce = 
plan_any.downcast_ref::<FilterExec>().is_some()
                   || plan_any.downcast_ref::<HashJoinExec>().is_some()
                   || plan_any.downcast_ref::<RepartitionExec>().is_some();
               if wrap_in_coalesce {
                   Some(Arc::new(CoalesceBatchesExec::new(
                       plan.clone(),
                       target_batch_size,
                   )))
               } else {
                   None
               }
           })
       }
   }
   ````
   
   This is very similar to how we iterator over vec/list in Rust or any other 
PF languages today, we do not need to implement different iterators again and 
again, but just pass the behavior as Closure/Lambda expression.
   
   
   



-- 
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]

Reply via email to