I agree for some cases, the change is useful. But the plan compatibility is more important for production, because many systems use the plan to generate an execution graph, and the execution graph is very probably relevant with the state/storage, if we breaks them, the state also crashed.
We can change the plan for necessary requirements, but within your PR, you did not solve that, almost all of the plan change are meaningless, can you stop doing that ? I do want to be awful when I upgrade to the next calcite version ~ Best, Danny Chan 在 2019年12月30日 +0800 PM3:04，Vladimir Sitnikov <[email protected]>，写道： > Danny>How much cases are there in production ? This example itself seems > very marginalized. I’m not against with it, I’m suspicious about the value > of the feature. > > It improves JdbcTest#testJoinManyWay 2 times or so. > > master. > JdbcTest#testJoinManyWay: 5.8sec > https://travis-ci.org/apache/calcite/jobs/630602718#L1646 > > with normalization fix: > JdbcTest#testJoinManyWay: 3.1sec > https://travis-ci.org/apache/calcite/jobs/630719276#L1432 > > The fix is vital for the proper support of EnumerableMergeJoin as well. > If EnumerableMergeJoin is activated, then JdbcTest#testJoinManyWay can't > complete within 5 minutes (see PR 1702) > > Vladimir
