[
https://issues.apache.org/jira/browse/HIVE-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siying Dong updated HIVE-2248:
------------------------------
Description:
Now if the two sides of comparison is of different type, we always convert both
to double and compare. It was a slight regression from the change in
https://issues.apache.org/jira/browse/HIVE-1638. The old UDFOP<Comparison>,
using GenericUDFBridge, always tried to find common type first.
The worse case is this: If you did "WHERE <BIGINT_COLUMN> = 0 ", we always
convert the column and 0 to double and compare, which is wasteful, though it is
usually a minor costs in the system. But it is easy to fix.
was:Now if the two sides of comparison is of different type, we always
convert both to double and compare. It was a slight regression from the change
in https://issues.apache.org/jira/browse/HIVE-1638. The old UDFOP<Comparison>,
using GenericUDFBridge, always tried to find common type first.
> Comparison Operators convert number types to common type instead of double if
> necessary
> ---------------------------------------------------------------------------------------
>
> Key: HIVE-2248
> URL: https://issues.apache.org/jira/browse/HIVE-2248
> Project: Hive
> Issue Type: Bug
> Reporter: Siying Dong
> Assignee: Siying Dong
>
> Now if the two sides of comparison is of different type, we always convert
> both to double and compare. It was a slight regression from the change in
> https://issues.apache.org/jira/browse/HIVE-1638. The old UDFOP<Comparison>,
> using GenericUDFBridge, always tried to find common type first.
> The worse case is this: If you did "WHERE <BIGINT_COLUMN> = 0 ", we always
> convert the column and 0 to double and compare, which is wasteful, though it
> is usually a minor costs in the system. But it is easy to fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
