> we could add some support in the engine to reduce the burden on the person writing the rule
Do you have any ideas? By the way, it looks like pull/1019 supercedes CALCITE-2223 (which addresses infinte planning). I've tried to use 1019 in Drill, and after a bit of tweaking (see https://github.com/vlsi/drill/compare/956d7a3db6ef4508e0fbcbc590782c927beb8322..CALCITE-pull1019 ) Note: tweaking was mostly guided by "Caused by: java.lang.IllegalStateException: Rule DrillFilterAggregateTransposeRule should specify desired traits for the root operand class org.apache.calcite.rel.core.Filter. Either pass a trait in the constructor parameter of a rule or use @ImplicitTrait for RelNode class" kind of errors raised by Calcite when it detects ambiguous rules. I've started org.apache.drill.TestProjectWithFunctions#testCastFunctions (the one that resulted in an infinite planning), and it ended up with CannotPlanException (oh, it creates a nice cycle between two mail threads). The nature of the fail is JoinToMultiJoinRule always produces MultiJoin that has NONE convention (==Calcite's logical), and this MultiJoin is put in the middle of Drill's logical nodes. Is there a reason why LogicalMultiJoin and RelFactories.MultiJoinFactory are missing? It looks like Calcite enforces MultiJoin to have Convention.NONE, thus it is unusable in Drill kind of rel tree. It looks like the true cause of CALCITE-2223 (infinite planning) is that rules create improper equivalences (e.g. Filter(Filter rule can match EnumerableFilter(EnumerableFilter( and produce LogicalFilter). Vladimir
