Stamatis>This is a change that most likely will have impact on many projects
I don't see how it will impact projects. Really. Are there projects that use up to date Calcite versions? Are they ready for adding a CI job to test with Calcite master branch? It is very disappointing to hear that it will impact many projects while there's zero evidence. Just in case you missed: PR#1703 produces ZERO user-visible differences in the execution plan output. Note: PR#1703 does not change optimizer rules, so it should even produce the same outputs (as you see, there are virtually zero changes to the execution plans in Calcite code). There's a single change regarding the plan, and that is PlannerTest which uses DIGEST_ATTRIBUTES (a non-default flag) For instance, Sort#computeSelfCost was broken in 1.14 https://issues.apache.org/jira/browse/CALCITE-1842, and nobody complained. In the same way, (broken) EnumerableNestedLoopJoin was added in 1.20 https://issues.apache.org/jira/browse/CALCITE-2969, and nobody complained. Just in case, EnumerableNestedLoopJoin did not account it would have to restart the inner input multiple times, so it underestimated the cost. I don't blame the authors/committers, but I highlight a couple of examples that produce noticeable plan changes where execution plans both have user-visible changes, and the plan could easily degrade (because the costing was screwed). There was not a single discussion on the number of test cases Calcite consumers would have to change in order to adapt new Join nodes in the execution plan output. It does not sound fair to block normalization (which is vital for performance) and push Join refactorings and cost adjustments like trivial changes. Vladimir
