[
https://issues.apache.org/jira/browse/CALCITE-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18116495#comment-18116495
]
Julian Hyde commented on CALCITE-7794:
--------------------------------------
Show me some numbers.
Do you believe this change is a surefire win, or does it only win on average?
Is there an algorithm for {{HepPlanner}} that is significantly better? In other
words, rather than accepting incremental changes, should we offer an
alternative implementation of {{{}HepPlanner{}}}?
> Reduce the work HepPlanner does per rule application attempt
> ------------------------------------------------------------
>
> Key: CALCITE-7794
> URL: https://issues.apache.org/jira/browse/CALCITE-7794
> Project: Calcite
> Issue Type: Improvement
> Reporter: Michael Braun
> Priority: Minor
> Labels: pull-request-available
>
> HepPlanner tries every rule in a collection against every vertex, so missed
> attempts
> can greatly outnumber matches.
> On every attempt, {{applyRule}} tests {{graph.vertexSet().contains(vertex)}}.
> Both
> call sites try every rule against the same vertex in a loop that only exits
> early on
> a match, so membership cannot change within it: 100 rules means 100 set
> lookups
> where one would do.
> On attempts that cannot match -- the large majority -- {{applyRule}} also
> allocates
> {{bindings}} and {{nodeChildren}} before calling {{matchOperands}}, which
> rejects on
> its first statement, and runs the {{ConverterRule}} and
> {{CommonRelSubExprRule}}
> branches, traversing a vertex's parents, before the operand is tested.
> Proposed: move the membership test to the two callers, which need it once per
> vertex;
> return early for an empty rule collection; and test the operand first in
> {{applyRule}}, splitting {{matchOperands}} into a thin entry point making
> that test
> and a body assuming it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
