[
https://issues.apache.org/jira/browse/DRILL-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180547#comment-15180547
]
Jinfeng Ni commented on DRILL-4467:
-----------------------------------
I think the original plan is valid, although I agree the plan looks confusing.
The ordinal reference $1, $2 in the Project on top of Scan is referring to
Scan's RowType fields, not the "columns" list (RowType is Calcite concept,
"columns" list is Drill's internal concept). In the original plan, Scan's
RowType is [threecf, row_key, twocf]. That's why $1 would be resolved to
row_key, and $2 could be resolved to 'twocf'. Such logic happens when Drill
converts Prel to POP. If $1 is resolved incorrectly to other column, then
Drill's execution will not return correct result at all. (Name-based execution
will not help here, since the plan contains a wrong column name).
The patch ensures the column list is in the same order as the fields in Scan's
RowType, that will help remove confusing. But I do not see that it fixes an
invalid plan, since the original plan itself is correct.
> Invalid projection created using PrelUtil.getColumns
> ----------------------------------------------------
>
> Key: DRILL-4467
> URL: https://issues.apache.org/jira/browse/DRILL-4467
> Project: Apache Drill
> Issue Type: Bug
> Reporter: Laurent Goujon
> Assignee: Jacques Nadeau
> Priority: Critical
> Fix For: 1.6.0
>
>
> In {{DrillPushProjIntoScan}}, a new scan and a new projection are created
> using {{PrelUtil#getColumn(RelDataType, List<RexNode>)}}.
> The returned {{ProjectPushInfo}} instance has several fields, one of them is
> {{desiredFields}} which is the list of projected fields. There's one instance
> per {{RexNode}} but because instances were initially added to a set, they
> might not be in the same order as the order they were created.
> The issue happens in the following code:
> {code:java}
> List<RexNode> newProjects = Lists.newArrayList();
> for (RexNode n : proj.getChildExps()) {
> newProjects.add(n.accept(columnInfo.getInputRewriter()));
> }
> {code}
> This code creates a new list of projects out of the initial ones, by mapping
> the indices from the old projects to the new projects, but the indices of the
> new RexNode instances might be out of order (because of the ordering of
> desiredFields). And if indices are out of order, the check
> {{ProjectRemoveRule.isTrivial(newProj)}} will fail.
> My guess is that desiredFields ordering should be preserved when instances
> are added, to satisfy the condition above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
