[
https://issues.apache.org/jira/browse/IMPALA-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096907#comment-18096907
]
ASF subversion and git services commented on IMPALA-10349:
----------------------------------------------------------
Commit ecc7381315bb7098fca0b6d8a0fa0af8093f4b3b in impala's branch
refs/heads/master from Steve Carlin
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=ecc738131 ]
IMPALA-14912: Calcite Planner: Fix date string parsing
This commit fixes parsing for the following date strings SQL
select DATE '1999-01-01';
select DATE "1999-01-01";
This essentially reverts an earlier fix, IMPALA-13525, which was
way more complicated than it needed to be. The Impala StringLiteral
already handles escaped strings, so there is no need to remove the
escapes within the Calcite parser. The changes in Parser.jj reflect
the major part of the reversion, as well as removing the ParserUtil.java
file.
A change also had to be made in the ImpalaRexExecutor where the constant
folding was done. This completes the UTF-8 constant folding commit for
the Calcite Planner (IMPALA-10349)
One more change was made with the unhex function. Unhex can return a
non-UTF8 string. Impala can handle this in a StringLiteral, but Calcite
cannot. Because of this, the constant folding for unhex when the string
is non-UTF8 is done at physical node creation time rather than during
the optimization phase.
Change-Id: Ia08071193f86423a0e548c6b6690993afdad6272
Reviewed-on: http://gerrit.cloudera.org:8080/24218
Reviewed-by: Aman Sinha <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
> Revisit constant folding on non-ASCII strings
> ---------------------------------------------
>
> Key: IMPALA-10349
> URL: https://issues.apache.org/jira/browse/IMPALA-10349
> Project: IMPALA
> Issue Type: Improvement
> Components: Frontend
> Reporter: Quanlong Huang
> Assignee: Csaba Ringhofer
> Priority: Critical
> Fix For: Impala 5.0.0
>
>
> Constant folding may produce non-ASCII strings. In such cases, we currently
> abandon folding the constant. See commit message of IMPALA-1788 or codes
> here:
> [https://github.com/apache/impala/blob/9672d945963e1ca3c8699340f92d7d6ce1d91c9f/fe/src/main/java/org/apache/impala/analysis/LiteralExpr.java#L274-L282]
> I think we should allow folding non-ASCII strings if they are legal UTF-8
> strings.
> Example of constant folding work:
> {code:java}
> Query: explain select * from functional.alltypes where string_col =
> substr('123', 1, 1)
> +-------------------------------------------------------------+
> | Explain String |
> +-------------------------------------------------------------+
> | Max Per-Host Resource Reservation: Memory=32.00KB Threads=3 |
> | Per-Host Resource Estimates: Memory=160MB |
> | Codegen disabled by planner |
> | |
> | PLAN-ROOT SINK |
> | | |
> | 01:EXCHANGE [UNPARTITIONED] |
> | | |
> | 00:SCAN HDFS [functional.alltypes] |
> | HDFS partitions=24/24 files=24 size=478.45KB |
> | predicates: string_col = '1' |
> | row-size=89B cardinality=730 |
> +-------------------------------------------------------------+
> {code}
> Example of constant folding doesn't work:
> {code:java}
> Query: explain select * from functional.alltypes where string_col =
> substr('引擎', 1, 3)
> +-------------------------------------------------------------+
> | Explain String |
> +-------------------------------------------------------------+
> | Max Per-Host Resource Reservation: Memory=32.00KB Threads=3 |
> | Per-Host Resource Estimates: Memory=160MB |
> | Codegen disabled by planner |
> | |
> | PLAN-ROOT SINK |
> | | |
> | 01:EXCHANGE [UNPARTITIONED] |
> | | |
> | 00:SCAN HDFS [functional.alltypes] |
> | HDFS partitions=24/24 files=24 size=478.45KB |
> | predicates: string_col = substr('引擎', 1, 3) |
> | row-size=89B cardinality=730 |
> +-------------------------------------------------------------+
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
