Aleksandr Efimov created IMPALA-15300:
-----------------------------------------
Summary: Calcite planner: narrow integer operands for Substrait
substring and round
Key: IMPALA-15300
URL: https://issues.apache.org/jira/browse/IMPALA-15300
Project: IMPALA
Issue Type: Sub-task
Components: Frontend
Reporter: Aleksandr Efimov
IMPALA-15297 maps Impala operators onto the Substrait functions they stand for
by name. Two of them need more than a name.
Substrait's substring takes its position and length as i32, and Impala declares
substr with bigint parameters, so the call arrives as SUBSTR(varchar, i64, i64)
and matches nothing. Round is the same mismatch the other way: Substrait's
round takes the digit count as i32 while Impala types it from the literal, so a
two-argument round arrives with an i8. Calcite's own SUBSTRING runs into this
here as well, so the width is Substrait's choice rather than an Impala quirk,
and Isthmus's own coercion takes the operand types as they come.
Narrow those operands to i32 before matching. Isthmus has a hook for supplying
different operands but it is package private; the converter itself is public,
so the narrowing belongs there, at the point where the two type systems meet,
rather than in a pass over the plan.
The narrowing is an explicit cast rather than a silent reinterpretation, which
Isthmus writes out with THROW_EXCEPTION behaviour. That is stricter than
Impala, which returns no rows rather than failing for a position past the i32
range. Substrait has no wider substring to target, so the choice is between
saying so in the plan and not exporting these queries at all.
Over the TPC-DS queries that carry Calcite goldens this takes the exporter from
84 of 110 to 96: substr accounts for ten of them and round for two.
A one-argument round stays out. Every Substrait round variant takes a digit
count, so there is nothing to match, and carrying it across would mean
inventing an operand rather than adjusting one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
