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. > >
