hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HIVE-8433) CBO loses a column during AST conversion
Date Fri, 17 Oct 2014 22:03:33 GMT

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

Sergey Shelukhin commented on HIVE-8433:
----------------------------------------

I was able to simplify newly failing query to:
select * from t1 order by t1.c_int+t1.key. Looks like the check cannot be moved before order
by clean up, it's just not a very good check. I will see if it can be improved. Otherwise
we can keep it in the old place for catching most cases, and keep the RowResolver-level fix
and exception to deal with this bug

> CBO loses a column during AST conversion
> ----------------------------------------
>
>                 Key: HIVE-8433
>                 URL: https://issues.apache.org/jira/browse/HIVE-8433
>             Project: Hive
>          Issue Type: Bug
>          Components: CBO
>            Reporter: Sergey Shelukhin
>            Assignee: Sergey Shelukhin
>            Priority: Critical
>         Attachments: HIVE-8433.patch
>
>
> {noformat}
> SELECT
>   CAST(value AS BINARY),
>   value
> FROM src
> ORDER BY value
> LIMIT 100
> {noformat}
> returns only one column.
> Final CBO plan is
> {noformat}
>   HiveSortRel(sort0=[$1], dir0=[ASC]): rowcount = 500.0, cumulative cost = {24858.432393688767
rows, 500.0 cpu, 0.0 io}, id = 44
>     HiveProjectRel(value=[CAST($0):BINARY(2147483647) NOT NULL], value1=[$0]): rowcount
= 500.0, cumulative cost = {0.0 rows, 0.0 cpu, 0.0 io}, id = 42
>       HiveProjectRel(value=[$1]): rowcount = 500.0, cumulative cost = {0.0 rows, 0.0
cpu, 0.0 io}, id = 40
>         HiveTableScanRel(table=[[default.src]]): rowcount = 500.0, cumulative cost =
{0}, id = 0
> {noformat}
> but the resulting AST has only one column. Must be some bug in conversion, probably related
to the name collision in the schema, judging by the alias of the column for the binary-cast
value in the AST
> {noformat} 
> TOK_QUERY
>    TOK_FROM
>       TOK_SUBQUERY
>          TOK_QUERY
>             TOK_FROM
>                TOK_TABREF
>                   TOK_TABNAME
>                      default
>                      src
>                   src
>             TOK_INSERT
>                TOK_DESTINATION
>                   TOK_DIR
>                      TOK_TMP_FILE
>                TOK_SELECT
>                   TOK_SELEXPR
>                      .
>                         TOK_TABLE_OR_COL
>                            src
>                         value
>                      value
>          $hdt$_0
>    TOK_INSERT
>       TOK_DESTINATION
>          TOK_DIR
>             TOK_TMP_FILE
>       TOK_SELECT
>          TOK_SELEXPR
>             TOK_FUNCTION
>                TOK_BINARY
>                .
>                   TOK_TABLE_OR_COL
>                      $hdt$_0
>                   value
>             value
>       TOK_ORDERBY
>          TOK_TABSORTCOLNAMEASC
>             TOK_TABLE_OR_COL
>                value
>       TOK_LIMIT
>          100
> {noformat}



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

Mime
View raw message