Changes to the rule pattern interface

Hi folks, Rules are an essential part of the Calcite-based query optimizers. A typical optimizer may require dozens of custom rules that are created by extending some Apache Calcite interfaces. During the last two years, there were two major revisions of how rules are created: 1. In early 1.2

Re: Changes to the rule pattern interface

I don't have any weight behind my opinion or experience, but anything that lowers the barrier to entry to Calcite for newcomers is a huge win in my mind. I assume the reason for the changes was because codegen improved performance? Could it make sense to allow both options, the easy/less-performa

Re: Changes to the rule pattern interface

Hello, The reasons for the planner rules configuration can be found here: CALCITE-3923 . See also the email thread [DISCUSS] Refactor how planner rules are parameterized

Re: Changes to the rule pattern interface

Vladimir, It's always good to ask these kinds of questions. e.g. "Is progress really progress?" I think moving to a configuration object was a substantial improvement. Until Java has default parameters and named parameters, I don't know of another good way to make rules sufficiently configurable

Re: Changes to the rule pattern interface

1. I agree with Jacques. Thanks, Vladimir, for asking the question ‘is progress really progress?’. We may not back out these changes (probably won’t) but it will inform future discussions. It’s valid to say ‘when did X as part of the rule refactoring, that didn’t deliver on promises’. 2. Thanks

Re: Changes to the rule pattern interface

I can say for myself that though the migration was a nuisance, after we figured out what to do, it was straightforward and the current approach with Immutables is more readable and easier to write than the previous with `operand` and `operandJ`. Viliam On Wed, 13 Apr 2022 at 19:23, Julian Hyde w

Re: Changes to the rule pattern interface

Hi, all, I think the rule configuration is not convenient for optional operand, such as a match operand tree Project | Union /\ FilterFilter If I want to compose a rule that the Project operand is optional, I must

Re: Changes to the rule pattern interface

Yanjing, That is a valid point. The API could perhaps allow people to define rules with nodes that are optional. Can you please log a JIRA for this? Include the code that you would like to write in order to define a rule and handle a match. Julian On Thu, Apr 14, 2022 at 2:27 AM Yanjing Wang wr

Re: Changes to the rule pattern interface

Hi, Thanks, everybody, for your comments. I want to clarify that my concern is not the ideas behind the changes (which are completely valid and valuable) but that users are _forced_ to use the new approach even for simple patterns. Walking through the peculiarities of RelRule.Config and Immutables