You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Aleksandr Efimov (Jira)" <ji...@apache.org> on 2026/08/26 01:40:00 UTC

[jira] [Created] (IMPALA-15307) Calcite planner: fixes from reading the Substrait export series whole

Aleksandr Efimov created IMPALA-15307:
-----------------------------------------

             Summary: Calcite planner: fixes from reading the Substrait export series whole
                 Key: IMPALA-15307
                 URL: https://issues.apache.org/jira/browse/IMPALA-15307
             Project: IMPALA
          Issue Type: Sub-task
          Components: Frontend
            Reporter: Aleksandr Efimov


Reading the series as one body of code, rather than one change at a time, turns up four things that each change on its own did not.

Operand narrowing reaches DECIMAL. Calcite's EXACT_TYPES is the integer types plus DECIMAL, so a decimal operand of substr or round was cast to an integer and everything after the point was dropped, silently. Narrowing now covers the integer types only, and a decimal operand is left as it is so the call is refused rather than answered wrongly.

Folding a constant interval multiply dereferences a literal's value without checking it. RexLiteral.getValueAs returns null for a NULL literal, so a plan carrying one failed with a NullPointerException reported as an internal fault instead of being refused with a reason.

The statistics visitor calls RelMetadataQuery outside the guard. A metadata handler can refuse a relation shape or find a cycle, and a plan that exported before carrying estimates would then be rejected — and, because the exporter classified by exception class, be told the fault was an unmapped function. The metadata calls are inside the guard now, and a lost estimate costs an estimate rather than an export. While there, the hint is built from what the relation already carries, so an alias or output names a later Isthmus attaches are not replaced by a hint holding statistics alone.

The provider held one visitor. ConverterProvider is memoized for the process and a SubstraitRelVisitor carries state for the conversion it is running, so every export would have answered with the resolver of whichever export built it. A fresh visitor per call, as the base class gives.



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