> I might be wrong, however, I did see "< vs >" normalization to reduce the > search space. I added the normalization performance rather than aesthetics > reasons.
Are you sure the performance gain is caused by "< vs >" normalization instead of "=" normalization? Can you show me the test case? > Note: innerjoin(S, S) does appear in practice, and it might benefit from < > vs > JoinCommuteRule won't apply on this kind of join, so that won't be a problem. On 2020/07/15 19:26:57, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: > > things might be bad if we want do dedup RexNode children using > Set<RexNode> > > I guess it is exactly the action RexSimplify does currently :-/ > https://github.com/apache/calcite/blob/3fb68f6c22a7bcbc4cb1fff114bc911b1e31c4de/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1377-L1380 > > >The Join operator e.g. innerjoin(S, R) generated by join reordering is not > equivalent with the original join innerjoin(R, S), > > I might be wrong, however, I did see "< vs >" normalization to reduce the > search space. I added the normalization performance rather than aesthetics > reasons. > > Note: innerjoin(S, S) does appear in practice, and it might benefit from < > vs > > > Vladimir >
