I agree with what Ted said. In this case, you could use HepPlanner to tidy up the tree - combining filters - before you go into the VolcanoPlanner phase.
Real-world planners use tricks such as multi-phase optimization, because otherwise there are combinatorial traps. Julian > On Aug 8, 2017, at 9:24 PM, Ted Xu <[email protected]> wrote: > > Hi JD, > > If you're using Volcano planner, it is common sense that applying rules > will expand search space. However, if you put your rules carefully, the > space expansion is linear to rule apply and rels. According to your test > result, it's better if you can check your rules to see if there is > exponential expansion (e.g., unlimited join ordering). > > There are still 2 ways to narrow down your search space, > > 1. Set RelNode importantce = 0 during optimzation, which tells the Volcano > planner to cease further exploration (rule apply) on the very RelNode. You > should use it carefully because it may cause CannotPlanException. > 2. Use HepPlanner instead of VolcanoPlanner. Instead of retaining all > optional plan, HepPlanner will heuristically choose one route at each rule > apply. The search space is very limited but you may get sub-optimal plan. > > Regards, > Ted Xu > >> On Wed, Aug 9, 2017 at 9:53 AM JD Zheng <[email protected]> wrote: >> >> Hi, >> >> We use RelBuilder to build logical relational algebra trees for our domain >> specific language. It is possible that the user might construct a >> relational algebra tree with several “where” clause. In this case, the >> RelBuilder will build a relnode tree with multiple filters one followed by >> another back to back. We noticed that the optimize time for such tree grows >> exponentially. For example, with 1 where clause, normally it took a few ms. >> However, with 7 where clauses, the optimize time will take almost 1 minute. >> >> Before I dig into the planner, does anyone encounter similar performance >> issue or have any suggestion as what to look into? Thanks, >> >> -JD
