You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Chunhui Shi (JIRA)" <ji...@apache.org> on 2018/01/02 21:30:00 UTC
[jira] [Comment Edited] (DRILL-5286) When rel and target candidate
set is the same, planner should not need to do convert for the relNode
since it must have been done
[ https://issues.apache.org/jira/browse/DRILL-5286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16308726#comment-16308726 ]
Chunhui Shi edited comment on DRILL-5286 at 1/2/18 9:29 PM:
------------------------------------------------------------
There is no change to result plans. This optimization is aimed to reduce the redundant convertChild calls on the same nodes for the same traits. With this change, the planning performance is improved.
Add a trace log to the original code as shown below, then we could count the occurrence of "convertChild to convert NODE" in log(trace level) to measure the improvement, since this occurrence represent how many time the next line ( convertChild) will be called.
RelNode newRel = RelOptRule.convert(candidateSet, rel.getTraitSet().plus(Prel.DRILL_PHYSICAL));
logger.trace("{}.convertChild to convert NODE {} ,AND {}", this.getClass().getSimpleName(), n, newRel);
RelNode out = convertChild(n, newRel);
And I randomly picked several TPCH queries as examples, the counts of this log occurrence comparison is listed as this:
With this optimization, Original - Without this change
tpch/5.sql 183 2385
tpch/10.sql 68 365
tpch/17.sql 118 605
tpch/20.sql 381 3839
While planning time is not a major part of a full performance run (TPCH queries on SF100). We did specifically run the performance run for this change once and it showed an improvement of ~1-2%, so the planning improvement is significant.
was (Author: cshi):
Add a trace log to the original code as shown below, then we could count the occurrence of "convertChild to convert NODE" in log(trace level) to measure the improvement, since this occurrence represent how many time the next line ( convertChild) will be called.
RelNode newRel = RelOptRule.convert(candidateSet, rel.getTraitSet().plus(Prel.DRILL_PHYSICAL));
logger.trace("{}.convertChild to convert NODE {} ,AND {}", this.getClass().getSimpleName(), n, newRel);
RelNode out = convertChild(n, newRel);
And I randomly picked several TPCH queries as examples, the counts of this log occurrence comparison is listed as this:
With this optimization, Original - Without this change
tpch/5.sql 183 2385
tpch/10.sql 68 365
tpch/17.sql 118 605
tpch/20.sql 381 3839
While planning time is not a major part of a full performance run (TPCH queries on SF100). We did specifically run the performance run for this change once and it showed an improvement of ~1-2%, so the planning improvement is significant.
> When rel and target candidate set is the same, planner should not need to do convert for the relNode since it must have been done
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: DRILL-5286
> URL: https://issues.apache.org/jira/browse/DRILL-5286
> Project: Apache Drill
> Issue Type: Bug
> Affects Versions: 1.12.0
> Reporter: Chunhui Shi
> Assignee: Chunhui Shi
> Labels: ready-to-commit
> Fix For: 1.13.0
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)