[
https://issues.apache.org/jira/browse/CALCITE-6907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17938327#comment-17938327
]
Julian Hyde commented on CALCITE-6907:
--------------------------------------
I suggest attacking this as you would any performance problem:
* Create a benchmark that is scalable via a parameter
* Commit the benchmark so that anyone can run it.
* Try making various changes to make the benchmark run faster.
* Try a variety of techniques to find out where the benchmark is REALLY
spending its time (stack sampling, count the number of RelNodes of each type,
the number of rules fired).
* See which parts of the algorithm get slower as you increase the parameter.
* Document your findings and your ideas. Present them to the wider team, and
start a discussion. Solicit ideas for changes (big and small) that might make
the algorithm better. Some ideas will be expensive and disruptive to implement,
so you will need to get buy-in.
> Optimize HepPlanner latency for large plan
> ------------------------------------------
>
> Key: CALCITE-6907
> URL: https://issues.apache.org/jira/browse/CALCITE-6907
> Project: Calcite
> Issue Type: Improvement
> Reporter: Wenzhuang Zhu
> Priority: Major
>
> HepPlanner cannot quickly optimize plan with 10K+ rel nodes.
> We can improve it by:
> 1.HepPlanner support graph reuse for different HepProgram.
> 2.Don't do eager graph gc, e.g. for listener and graph iterator.
> 3.Use large plan friendly graph iterator.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
