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