Normalizing scalar expressions is helpful, especially for deduplicating derived constraints that is pushed down to child relations. We should not stop making improvements just because there are many plan changes.
How about adding optimizer config option to enable/disable the feature? Normalizing every binary operator might seem not necessary, but simply normalizing equal expression with input refs or literals alone can still help a lot, I guess, because many of them are generated from equivalent classes. - Haisheng ------------------------------------------------------------------ 发件人：Rui Wang<amaliu...@apache.org> 日 期：2019年12月31日 07:09:44 收件人：<dev@calcite.apache.org> 主 题：Re: [DISCUSS] CALCITE-2450 reorder predicates to a canonical form I think the concern of breaking plan comparison has appeared more than once. Not only to this proposal but also to others (e.g. replace "$" with "_" in names). From a think of another perspective, the widely used practice of string comparison based plan evaluation also reduces the flexibility of making changes in Calcite. We need to carefully think about if a change has a large impact that affects toString(), or something similar. So if Calcite community could offer another solution for downstream projects, and announce that don't guarantee the backward compatibility of toString(), then it could be in a better situation. A few candidate solutions: 1. offer utils that convert a plan represented in string to Relnodes. 2. use RelBuilder to build plans and does comparison. and then just maintain the backward compatibility of the solution. just my two cents. -Rui On Mon, Dec 30, 2019 at 12:20 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > The change improves slow tests from 80 min to 60, and the changes are > minimal > > Vladimir >
