[
https://issues.apache.org/jira/browse/CALCITE-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16593265#comment-16593265
]
Vladimir Sitnikov commented on CALCITE-2470:
--------------------------------------------
{quote}Thanks for noticing this. It looks as if the input fields were permuted
at an early stage, and therefore GROUPING($2, $3, $7) has changed to
GROUPING($3, $2, $7). But note that in the the EnumerableCalc and
EnumerableAggregate that consume it,{quote}
I wonder what triggers that permutation.
Do you remember that {{java.lang.Class#getFields}} does NOT define the order of
the fields?
I wonder if the permutation is related to CALCITE-2489
> RelBuilder.project should combine expressions if underlying node is a Project
> -----------------------------------------------------------------------------
>
> Key: CALCITE-2470
> URL: https://issues.apache.org/jira/browse/CALCITE-2470
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
> Priority: Major
> Fix For: 1.18.0
>
>
> The {{RelBuilder.project}} method should combine expressions if underlying
> node is a {{Project}}.
> For example, if {{r}} is a {{RelBuilder}} and its stack initially contains
> {code:java}
> Project(Scan(T), a, b, a + b as c){code}
> and we call (in pseudo-code)
> {code:java}
> r.project(a + c as d){code}
> then the result should be
> {code:java}
> Project(Scan(T), a + (a + b) as d){code}
> Today the result is
> {code:java}
> Project(Project(Scan(T), a, a + b as c), a + c as d){code}
> In some circumstances the result will be larger (i.e. contain more
> {{RexNode}} instances) but much more frequently the result will be smaller
> and simpler.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
