Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
Date
Msg-id 200002060441.XAA22920@candle.pha.pa.us
Whole thread Raw
In response to Optimizer cleanup to avoid redundant work on joins  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
List 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 by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: [HACKERS] pg_ctl man page
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Solaris regression tests.