The shuffling is already part of a Hep phase [1] although the same planner is reused to take advantage of metadata caching etc.
If people feel otherwise then we don't really need to have something super customisable but just the option to use it or not in a more friendly way than a system property. As others mentioned, RelBuilder already has some optimizations that can be turned on/off so it seems like a good place to put the current normalization logic. We could extract the current normalization from RexCall#equals, etc., and put it in the most common methods of the RelBuilder. For example: RelBuilder#project RelBuilder#filter RelBuilder#join + variants Best, Stamatis [1] https://github.com/apache/hive/blob/6e8936fbb725450250271552c683f7b76bc38d93/ql/src/java/org/apache/hadoop/hive/ql/parse/CalcitePlanner.java#L2492 On Wed, Mar 10, 2021 at 11:19 AM Vladimir Sitnikov < [email protected]> wrote: > Julian> If Hive doesn't want its ANDs re-ordered, i > > I'm afraid that is a non-starter for Hive use case. > Replacing all ANDs with CASE would defeat simplified and it would defeat > lots of rules. > > Julian> * Make normalization less aggressive > > It still looks like a customization. > > There's one more option: admit that "AND operand shuffling" is a peephole > optimization, > and put the shuffling into a separate Hep phase. > Then Calcite's normalization does not hurt, and the use case does not > justify the need for a custom normalizer. > > Vladimir >
