[
https://issues.apache.org/jira/browse/CALCITE-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17953755#comment-17953755
]
Mihai Budiu edited comment on CALCITE-7024 at 5/23/25 5:55 PM:
---------------------------------------------------------------
While working on this I noticed that the Frame object, which is used by the
decorrelator, sometimes has "gaps" in the oldOutputsToNewOutputs. For example,
I have seen an aggregate where the map is [1 -> 1].
This looks to me like a bug, but it would be nice if someone who knows the
invariants on this object could confirm it. What makes it even more look like a
bug is that while creating the map first 1 is mapped to 0, then 1 is mapped to
1, overwriting the previous mapping. (This happens while processing an
Aggregate.)
If the map can have gaps, then it's not a good tool to trim the excess fields.
was (Author: JIRAUSER295926):
While working on this I noticed that the Frame object, which is used by the
decorrelator, sometimes has "gaps" in the oldOutputsToNewOutputs. For example,
I have seen an aggregate where the map is {1 -> 1}.
This looks to me like a bug, but it would be nice if someone who knows the
invariants on this object could confirm it. What makes it even more look like a
bug is that while creating the map first 1 is mapped to 0, then 1 is mapped to
1, overwriting the previous mapping. (This happens while processing an
Aggregate.)
If the map can have gaps, then it's not a good tool to trim the excess fields.
> Decorrelator does not always produce a query with the same type signature
> -------------------------------------------------------------------------
>
> Key: CALCITE-7024
> URL: https://issues.apache.org/jira/browse/CALCITE-7024
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.39.0
> Reporter: Mihai Budiu
> Assignee: Mihai Budiu
> Priority: Minor
>
> While trying to implement [CALCITE-7023] I stumbled on some examples for
> which the query produced by the decorrelator has a different type signature
> from the input query. I think this should be impossible.
> Original plan:
> {code}
> LogicalCorrelate(correlation=[$cor0], joinType=[left],
> requiredColumns=[{0}]), id = 161
> LogicalTableScan(table=[[schema, s]]), id = 95
> LogicalSort(fetch=[1]), id = 159
> LogicalAggregate(group=[{}], EXPR$0=[SUM($0)]), id = 157
> LogicalProject(x=[$0]), id = 155
> LogicalFilter(condition=[=($cor0.y, $1)]), id = 153
> LogicalTableScan(table=[[schema, t]]), id = 97
> {code}
> Error produced when attempting to replace this plan after decorrelating it:
> {code}
> set type is RecordType(INTEGER y, DECIMAL(28, 2) EXPR$0) NOT NULL
> expression type is RecordType(INTEGER y, DECIMAL(28, 2) EXPR$0, INTEGER z)
> NOT NULL
> set is
> rel#161:LogicalCorrelate.(left=HepRelVertex#151,right=HepRelVertex#160,correlation=$cor0,joinType=left,requiredColumns={0})
> expression is LogicalJoin(condition=[=($0, $2)], joinType=[left])
> LogicalTableScan(table=[[schema, s]])
> LogicalProject(EXPR$0=[FIRST_VALUE($1) OVER (PARTITION BY $0)], z=[$0])
> LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)])
> LogicalProject(z=[$1], x=[$0])
> LogicalFilter(condition=[IS NOT NULL($1)])
> LogicalTableScan(table=[[schema, t]])
> Type mismatch: the field sizes are not equal.
> rowtype of original rel: RecordType(INTEGER y, DECIMAL(28, 2) EXPR$0) NOT NULL
> rowtype of new rel: RecordType(INTEGER y, DECIMAL(28, 2) EXPR$0, INTEGER z)
> NOT NULL
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
