[ https://issues.apache.org/jira/browse/HIVE-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832020#comment-13832020 ]
Sergey Shelukhin commented on HIVE-5817: ---------------------------------------- About the other operators, what do you mean? In the explain of the original query I was looking at, vectorized select does this {noformat} Select Operator expressions: expr: _col22 type: string expr: _col53 type: float outputColumnNames: _col0, _col1 {noformat} In that case, _col22 from 2 preceding joins happened to collide, but cannot, for example, _col1 from the last join become _col0 of select? So the collision will happen when _col1 of select is added and there's already _col1 from the last join > column name to index mapping in VectorizationContext is broken > -------------------------------------------------------------- > > Key: HIVE-5817 > URL: https://issues.apache.org/jira/browse/HIVE-5817 > Project: Hive > Issue Type: Bug > Components: Vectorization > Reporter: Sergey Shelukhin > Assignee: Remus Rusanu > Priority: Critical > Attachments: HIVE-5817-uniquecols.broken.patch, > HIVE-5817.00-broken.patch, HIVE-5817.4.patch > > > Columns coming from different operators may have the same internal names > ("_colNN"). There exists a query in the form {{select b.cb, a.ca from a JOIN > b ON ... JOIN x ON ...;}} (distilled from a more complex query), which runs > ok w/o vectorization. With vectorization, it will run ok for most ca, but for > some ca it will fail (or can probably return incorrect results). That is > because when building column-to-VRG-index map in VectorizationContext, > internal column name for ca that the first map join operator adds to the > mapping may be the same as internal name for cb that the 2nd one tries to > add. 2nd VMJ doesn't add it (see code in ctor), and when it's time for it to > output stuff, it retrieves wrong index from the map by name, and then wrong > vector from VRG. -- This message was sent by Atlassian JIRA (v6.1#6144)