[ https://issues.apache.org/jira/browse/HIVE-14893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583221#comment-15583221 ]
Sergey Shelukhin commented on HIVE-14893: ----------------------------------------- [~mmccline] [~hagleitn] la la la > vectorized execution may convert LongCV to smaller types incorrectly > -------------------------------------------------------------------- > > Key: HIVE-14893 > URL: https://issues.apache.org/jira/browse/HIVE-14893 > Project: Hive > Issue Type: Bug > Reporter: Sergey Shelukhin > Assignee: Matt McCline > Priority: Critical > > See the results for vectorized in decimal_11 test added in HIVE-14863. > We cast decimal to various int types; the cast is specialized for each type > on non-vectorized side; on vectorized side, it's only specialized for > LongColumnVector, so all the decimals get converted to longs. > LongColumnVector gets converted to a proper type in some other mysterious > place later, and tiny/small/regular ints become truncated at that point. > Logically, I am not sure if every vectorized expression should be aware of > the underlying type for the LongColumnVector (that seems implausible - I am > not sure if type information is even available, and if yes it doesn't look > like it's used in other places), or if the long-to-smaller-type automatic > conversion should be fixed to produce nulls on overflow. > However it seems like a good idea to do the latter in any case, to have a > catch-all for all the vectorized expressions that might treat LongCV as > representing longs at all times. > Update - I see 10s of places in the code where it does something like this: > {noformat}(int) ((LongColumnVector) > batch.cols[projectionColumnNum]).vector[adjustedIndex]{noformat} > Also for other types. These might all be problematic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)