Mailing-List: contact issues-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Date: Wed, 8 Jun 2016 00:02:21 +0000 (UTC)
From: "Sergey Shelukhin (JIRA)" <jira@apache.org>
To: issues@hive.apache.org
Message-ID: <JIRA.12976586.1465327701000.21815.1465344141008@Atlassian.JIRA>
In-Reply-To: <JIRA.12976586.1465327701000@Atlassian.JIRA>
References: <JIRA.12976586.1465327701000@Atlassian.JIRA> <JIRA.12976586.1465327701258@arcas>
Subject: [jira] [Commented] (HIVE-13963) vectorization - string arguments
 may be converted to decimal null
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 08 Jun 2016 00:02:22 -0000


    [ https://issues.apache.org/jira/browse/HIVE-13963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319735#comment-15319735 ] 

Sergey Shelukhin commented on HIVE-13963:
-----------------------------------------

[~xuefuz] see the new Q file added in  HIVE-13957. Before the fix there (that disables vectorization for IN for such cases), the vectorized query returns no results. 
The code in vectorization that adds casts to arguments (before evaluating them) for UDFs like IN, and gets precision and scale for the cast depending on the type, is the problem.

> vectorization - string arguments may be converted to decimal null
> -----------------------------------------------------------------
>
>                 Key: HIVE-13963
>                 URL: https://issues.apache.org/jira/browse/HIVE-13963
>             Project: Hive
>          Issue Type: Bug
>            Reporter: Sergey Shelukhin
>            Assignee: Matt McCline
>            Priority: Critical
>
> See HIVE-13957.
> The default precision and scale for the implicit decimal cast are max,max, ie 38,38. Those don't do what the code may assume they do. All the values > 0 become invalid and precision-scale enforcement automatically converts them to null.
> We need to 
> 1) Validate when this happens in/after the conversion code and bail;
> 2) Or, derive precision and scale from the constants themselves so they all fit, instead;
> 3) Or, derive it from the type of whatever caused the conversion in the first place (e.g. IN column decimal); however, this could be function-specific (e.g. IN just needs equality, BETWEEN would need at least one extra digit, arithmetic, if this ever happens, would need everything, etc.);
> 4) Something else? :)


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)