[
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:44 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 comparison of
counts of this log occurrence is listed as this:
|| Query || 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):
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 comparison of
counts of this log occurrence is listed as this:
|| Query || 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)
