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)