If the number of operands is greater than a threshold, like 5, or 10, we can just stop normalizing it. But currently AND/OR in Calcite is always binary operator, IN is not supported in RexNode world.
Anyway, the discussion is orthogonal with your pull request, and it doesn't block the proceeding of your PR. On 2020/07/16 02:16:18, Danny Chan <yuzhao....@gmail.com> wrote: > Well, I think I now got your idea, I agree a specific operator sub-class plus > a special symmetric hash code is more efficient and extensible. But for the > first version, I would only consider binary operators because I could not > figure out how to implement an efficient equals for operator like IN. > > Best, > Danny Chan > 在 2020年7月16日 +0800 AM1:55，Haisheng Yuan <hy...@apache.org>，写道： > > > Customized sql operator can also benefit. [1] > > > > I am not sure if I missed something. Can you show me how can the customized > > sql operator benefit from this? > > e.g. geospatial operator intersect (it is input order insensitive): > > boolean &&( geometry A , geometry B ) > > > > > Add a SqlOperator interface is not that feasible because most of the > > > operators share the same class > > > > Really? How hard it is to create a SqlOrderInsensitiveBinaryOperator that > > just override inputOrderSensitive() method? like how > > SqlMonotonicBinaryOperator does. > > > > > Eagerly computed hashcode for operand should not be a problem because > > > sooner or later the hashcode would be computed in the digest cache of the > > > planner and the RexCall already has a hashcode cache. > > > > The thing is do we have to do all the gymnastics like normalization for > > input order insensitive operator when just computing the hash code? Is it > > the best we can do? > > > > Currently It is limited to sql operator with 2 operands. What if I have a > > customized sql operand AND/OR that can accept more than 2 operands? > > > > On 2020/07/15 06:34:55, Danny Chan <yuzhao....@gmail.com> wrote: > > > I have extended the logic to support all the symmetrical operators(=, <> > > > ..) and the binary comparison operators (>=, < ..), > > > not only just RexInputRef. Customized sql operator can also benefit. [1] > > > > > > The way is to compare the operands with SqlKind first then fallback to > > > their hashcode (eargely computed). > > > > > > Add a SqlOperator interface is not that feasible because most of the > > > operators share the same class (for example, SqlBinaryOperator) with > > > different SqlKind. Instead, the current code has a special SqlKind to > > > distinguish the operators we want to normalize which I think is a better > > > way. > > > > > > Eagerly computed hashcode for operand should not be a problem because > > > sooner or later the hashcode would be computed in the digest cache of the > > > planner and the RexCall already has a hashcode cache. > > > > > > We actually don’t really need to care about what the operands sort > > > algorithm is, only if: > > > > > > > > > • the algorithm is deterministic > > > • It can cover most of the cases, like the user defined function > > > • It does not affect the performance too much > > > > > > [1] https://github.com/apache/calcite/pull/2065 > > > > > > Best, > > > Danny Chan > > > 在 2020年7月15日 +0800 PM12:10，dev@calcite.apache.org，写道： > > > > > > > > Sql operators like EQUALS, NOT_EQUALS, AND, OR should return false to > > > > indicate they are not input order sensitive. > > > >
