Bushy Plans fixed
От | Bruce Momjian |
---|---|
Тема | Bushy Plans fixed |
Дата | |
Msg-id | 199902180047.TAA09309@candle.pha.pa.us обсуждение исходный текст |
Ответы |
Re: [HACKERS] Bushy Plans fixed
|
Список | pgsql-hackers |
I have fixed bushy plans, enabled with the postgres -b option. Here is proof from OPTIMIZER_DEBUG: levels left: 7(9 8 7 6 ): size=1 width=16 path list: Nestloop size=1 cost=0.000000 MergeJoinsize=1 cost=0.000000 clauses=(x5.y = x6.y) sortouter=1 sortinner=1 SeqScan(6) size=0 cost=0.000000 SeqScan(7) size=0 cost=0.000000 MergeJoin size=1 cost=0.000000 clauses=(x7.y = x8.y) sortouter=1 sortinner=1 SeqScan(8) size=0 cost=0.000000 SeqScan(9)size=0 cost=0.000000 The regression tests pass with bushy plans enabled. I am not sure if the executor is actually using a bushy plan, though. The old bushy code was poor. It tried to do bushy plans by modifying the joininfo nodes. I removed all that code, and just do the join search in make_rels_by_clause_joins(). This is much more logical, and does not require the joininfo setup/cleanup that the old code attempted. Frankly, I would like to enable bushy plans and right-handed plans by default. The optimizer is now fast enough that a 9-table join is almost instantaneous, even with bush plans. People are not sophisticated enough to know when to enables these options themselves. I am not sure I am either. I would like to enables both, fix whatever breaks, and programmatically enable the options when they make sense. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: