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

ASF subversion and git services commented on IMPALA-13430:
----------------------------------------------------------

Commit 36d341c4311d70b35fc476a4a93cf509759317bb in impala's branch 
refs/heads/master from Steve Carlin
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=36d341c43 ]

IMPALA-13430: Too many RelNodes created for "IN" literals

The "withCreateValuesRel" false config parameter causes a "value" node
to be created for every literal in an "in" clause. This slows down
the compilation time and runtime massively. By removing this
parameter (using the 'true' default), all literal values are placed
within one Values RelNode.

Changing this parameter exposed a bug in tpcds q8. The CoerceNodes
module explicitly creates a Project node above a Values node when
the values node contains a string literal. Unfortunately, a Calcite
limitation prevents the string literal to be of type "string" but
instead is of type "char(x)".

Because of this limitation this Project hack was created. When
converting Calcite RelNodes to Impala RelNodes, we "notify" the
Values RelNode that it should ignore the row datatypes of the current
Values RelNode and instead use the parent row datatypes.

Change-Id: Ifc3d84c70af9cd4db44359c4ab7f0c9eb70738f5
Reviewed-on: http://gerrit.cloudera.org:8080/21911
Reviewed-by: Impala Public Jenkins <[email protected]>
Tested-by: Michael Smith <[email protected]>


> Calcite planner: test_exprs test_expr_child_limit runs slow
> -----------------------------------------------------------
>
>                 Key: IMPALA-13430
>                 URL: https://issues.apache.org/jira/browse/IMPALA-13430
>             Project: IMPALA
>          Issue Type: Sub-task
>            Reporter: Steve Carlin
>            Priority: Major
>             Fix For: Impala 4.5.0
>
>
> This is running slow because it is creating a new Values RelNode for every 
> value in the IN clause.  A config parameter can fix this



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to