[jira] [Updated] (CALCITE-4392) The operation of checking types equal ignoring null can be more efficient

["Liya Fan (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liya Fan updated CALCITE-4392:
------------------------------
    Description: 
Method {{SqlTypeUtil#equalSansNullability(RelDataTypeFactory, RelDataType, RelDataType) is on the hot path for many scenarios, as it compare types with nullability ignored.

In the implementation, the expensive operations are {{RelDataType#equals(Object)}} and {{RelDataTypeFactory#createTypeWithNullability}}, especially for types with multiple sub-fields. 

For the current implementation, the {{RelDataType#equals(Object)}} is called at least once, and {{RelDataTypeFactory#createTypeWithNullability}} is called whenever the nullability values are different. 

We can improve the implementation so that {{RelDataType#equals(Object)}} is called at most once, and the call to {{RelDataTypeFactory#createTypeWithNullability}} can be avoided if the types are totally different (with different type names, and nullability values)

{noformat}
if (type1.isNullable() == type2.isNullable()) {
  return type1.equals(type2);
} else {
  return type1.equals(
        factory.createTypeWithNullability(type2, type1.isNullable()));
}
{noformat}

  was:
Method {{SqlTypeUtil#equalSansNullability(RelDataTypeFactory, RelDataType, RelDataType) is on the hot path for many scenarios, as it compare types with nullability ignored.

In the implementation, the expensive operations are {{RelDataType#equals(Object)}} and {{RelDataTypeFactory#createTypeWithNullability}}, especially for types with multiple sub-fields. 

For the current implementation, the {{RelDataType#equals(Object)}} is called at least once, and {{RelDataTypeFactory#createTypeWithNullability}} is called whenever the nullability values are different. 

We can improve the implementation so that {{RelDataType#equals(Object)}} is called at most once, and the call to {{RelDataTypeFactory#createTypeWithNullability}} can be avoided if the types are totally different (with different type names, and nullability values)

{{noformat}}
if (type1.isNullable() == type2.isNullable()) {
  return type1.equals(type2);
} else {
  return type1.equals(
        factory.createTypeWithNullability(type2, type1.isNullable()));
}
{{noformat}}


> The operation of checking types equal ignoring null can be more efficient
> -------------------------------------------------------------------------
>
>                 Key: CALCITE-4392
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4392
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>            Reporter: Liya Fan
>            Assignee: Liya Fan
>            Priority: Major
>
> Method {{SqlTypeUtil#equalSansNullability(RelDataTypeFactory, RelDataType, RelDataType) is on the hot path for many scenarios, as it compare types with nullability ignored.
> In the implementation, the expensive operations are {{RelDataType#equals(Object)}} and {{RelDataTypeFactory#createTypeWithNullability}}, especially for types with multiple sub-fields. 
> For the current implementation, the {{RelDataType#equals(Object)}} is called at least once, and {{RelDataTypeFactory#createTypeWithNullability}} is called whenever the nullability values are different. 
> We can improve the implementation so that {{RelDataType#equals(Object)}} is called at most once, and the call to {{RelDataTypeFactory#createTypeWithNullability}} can be avoided if the types are totally different (with different type names, and nullability values)
> {noformat}
> if (type1.isNullable() == type2.isNullable()) {
>   return type1.equals(type2);
> } else {
>   return type1.equals(
>         factory.createTypeWithNullability(type2, type1.isNullable()));
> }
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)