Hi Weijie, As you might imagine Busy joins have pros and cons compared to Left-deep only plans: The main pro is that they enumerate a lot more plan choices such that the planner is likely to find the optimal join order. On the other hand, there are significant cons: (a) by enumerating more join orders, they would substantially increase planning time (depending on the number of tables). (b) the size of the intermediate results produced by the join must be accurately estimated in order to avoid situations where hash join build side turns out to be orders of magnitude more than estimated. This could happen easily in big data systems where statistics are constantly changing due to new data ingestion and even running ANALYZE continuously is not feasible. That said, it is not a bad idea to experiment with such plans with say more than 5 table joins and compare with left-deep plans.
Aman On Mon, May 27, 2019 at 7:00 AM weijie tong <[email protected]> wrote: > Hi all: > Does anyone know why we don't support bushy join in the query plan > generation while hep planner is enabled. The codebase shows the fact that > the PlannerPhase.JOIN_PLANNING use the LoptOptimizeJoinRule not calcite's > MultiJoinOptimizeBushyRule. >
