Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
Дата
Msg-id 200002060441.XAA22920@candle.pha.pa.us
обсуждение исходный текст
Ответ на Optimizer cleanup to avoid redundant work on joins  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> This looks like it should be a fairly straightforward change: we should
> meld make_join_rel and get_join_rel so that a requested join rel is
> first searched for in root->join_rel_list, and only built if not present
> (like get_base_rel).  The join rel would have a flat relids list from the
> beginning, since it would be agnostic about which inner and outer subset
> rels should be used to produce it.  Then update_rels_pathlist_for_joins
> would be called *immediately* to process just that one join rel, passing
> the outer and inner subset relid lists as separate parameters.  It would
> generate paths using this pair of outer and inner rels, and would add
> them to the join rel's path list only if they survive comparison against
> all the already-found paths for that join rel.  On return from
> make_rels_by_joins, all the work is done, so make_one_rel_by_joins
> doesn't need to invoke either update_rels_pathlist_for_joins or
> merge_rels_with_same_relids (the latter routine disappears entirely).
> We have but to invoke rels_set_cheapest and then advance to the next
> level of joining.
> 
> With this change, I could add more processing to make_join_rel to set
> the estimated output rel size, without fear that it would be repeated
> uselessly.
> 
> Anyone see a problem with this, or have a better idea about how to do
> it?

Sounds good.  The only question is how easy it will be to see if there
already is a RelOptInfo for that combination.  My guess is that the
current code is brain-dead like the many fixes we made long ago.  It was
carrying around too many versions, instead of keeping the cheapest. 
Seems you have found another place that should be doing this.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@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 по дате отправления:

Предыдущее
От: Thomas Lockhart
Дата:
Сообщение: Re: [HACKERS] pg_ctl man page
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Solaris regression tests.