alamb commented on issue #237: URL: https://github.com/apache/arrow-datafusion/issues/237#issuecomment-834695012
@Dandandan > @alamb just picking your brain here - do you think this should be part of the logical optimizations or physical optimizations? I think the suggested route (re-use evaluation code) is only feasible for the physical optimization, not the logical optimization rules. I would imagine this to be done on `Exprs`, not `PhysicalExprs` to allow the rewritten expressions to be used as much as possible by other optimization passes (e.g. filter and projection pushdown, which is done at the `LogicalPlan` level) > I am wondering here in general, whether we can/should unify LogicalPlan/PhysicalPlan Expr/PhysicalExpr a bit more in order to not have to write two versions of the same thing or being limited in the optimizations / optimization order. I think the LogicalPlan / PhysicalPlan distinction makes sense (b/c logically a Join is just a Join -- but physically maybe we would be using a CROSS JOIN w/ filter, or an Hash Inner Join, or a Merge Join, etc) I am not as sure about the distinction between `Expr` and `PhysicalExpr` -- I haven't looked carefully at the code to know what additional information a `PhysicalExpr` needs that an `Expr` doesn't have -- and you can make a `PhysicalExpr` from an `Expr` and a `Schema` [code link](https://github.com/apache/arrow-datafusion/blob/master/datafusion/src/physical_plan/planner.rs#L431) If we could directly evaluate `Exprs` without having to apply a transformation to them that would be pretty cool (and clean up a lot of duplication I think) -- 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. For queries about this service, please contact Infrastructure at: [email protected]
