[ https://issues.apache.org/jira/browse/CALCITE-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17324605#comment-17324605 ]
Vladimir Ozerov edited comment on CALCITE-4559 at 4/19/21, 8:05 AM: -------------------------------------------------------------------- The design looks great to me in general. I would like to highlight two potential improvements: # Patterns might be extremely complicated. In our practice, we observed situations like "the disjunctive expression that have attributes from two inputs on the one side and non-equi condition on the other side". The current approach is not flexible enough - most classes are hidden from the user, and the composition of static checks might be not sufficient. In the general case, a user might need to execute a complex visitor on the expression, to check whether it matches the rule. I would suggest defining a public pattern interface that allows for user-defined implementations. The {{OperandDetailBuilder}} might be a convenient basic implementation for the user, but not the only option. # Rex patterns might be useful outside of the {{RexRule}}. For example, a user might want to implement a {{RelRule}} that matches a {{Filter}} with very special requirements to the condition. Converting {{RexRuleProgram.Operand}} to a separate public interface (e.g., {{RexPattern}}), might be very helpful. Also, heuristic rule programs are very sensitive to the order of rule application. Currently, the rules are applied bottom-up only. There is a chance that in the future we may need alternative strategies. But perhaps it could be put out of the scope for now. was (Author: vozerov): The design looks great to me in general. I would like to highlight two potential improvements: # Patterns might be extremely complicated. In our practice, we observed situations like "the disjunctive expression that have attributes from two inputs on the one side and non-equi condition on the other side". The current approach is not flexible enough - most classes are hidden from the user, and the composition of static checks might be not sufficient. In the general case, a user might need to execute a complex visitor on the expression, to check whether it matches the rule. I would suggest defining a public pattern interface that allows for user-defined implementations. The `OperandDetailBuilder` might be a convenient basic implementation for the user, but not the only option. # Rex patterns might be useful outside of the `RexRule`. For example, a user might want to implement a `RelRule` that matches a `Filter` with very special requirements to the condition. Converting {{RexRuleProgram.Operand}} to a separate public interface (e.g., {{RexPattern}}), might be very helpful. Also, heuristic rule programs are very sensitive to the order of rule application. Currently, the rules are applied bottom-up only. There is a chance that in the future we may need alternative strategies. But perhaps it could be put out of the scope for now. > Create 'interface RexRule', a modular rewrite for row-expressions > ----------------------------------------------------------------- > > Key: CALCITE-4559 > URL: https://issues.apache.org/jira/browse/CALCITE-4559 > Project: Calcite > Issue Type: Bug > Reporter: Julian Hyde > Assignee: Julian Hyde > Priority: Major > > We propose to add {{class RexRule}}, a rewrite rule for row-expressions > ({{class RexNode}}). > {{class RexRule}} is analogous to how {{class RelRule}} (and the older > {{class RelOptRule}}) operates on relational expressions ({{interface > RelNode}}). Also, {{class RexRuleProgram}} is analogous to {{HepProgram}} and > {{VolcanoPlanner}} (it indexes rules so that we do not have to try every rule > against every part of the expression). And a rule describes which operands it > matches using {{RexRule.describe(RexRule.OperandBuilder)}}, similar to > calling {{RelRule.Config.operandSupplier().apply()}}. > The advantages of {{RexRule}} are similar to {{RelRule}}: rules can be > defined in a modular way, can be documented and tested individually, and can > be enabled individually. > The rules could be applied in various ways. {{RelBuilder.Config}} could > contain a {{RexRuleProgram}} that would be applied every time an expression > is simplified by a {{RelBuilder}}. There could also be a sub-class of > {{interface RelShuttle}} that applies the rules to every {{RexNode}} in a > tree (e.g. inside {{Filter}}, {{Project}} and {{Join}}). > I don't yet know whether, or how, rules might support 3-valued boolean logic > ({{RexUnknownAs}}). For example, a rule that simplifies "x = x" to "TRUE" is > valid in an "unknownAsFalse" context (e.g. as top-level of {{Filter}} > condition), but not in an "unknownAsUnknown" context (e.g. in {{Project}} > expression). > This case is related to CALCITE-3470 (making relational and row-expression > rules more similar, as in CockroachDB), but would deliver an API rather than > a textual DSL. -- This message was sent by Atlassian Jira (v8.3.4#803005)