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 <jdh...@gmail.com> 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

Reply via email to