Re: [HACKERS] Optimizer speed and GEQO (was: nested loops in joins)

> I have been looking at optimizer runtime using Charles Hornberger's
> example case, and what I find is that the number of tables involved in
> the query is a very inadequate predictor of the optimizer's runtime.
> Thus, it's not surprising that we are getting poor results from using
> number of tables as the GEQO threshold measure.

OK, now I have a specific optimizer question. I looked at all
references to RelOptInfo.pathlist, and though it gets very long and hard
to check for uniqueness, the only thing I see it is used for it to find
the cheapest path.

Why are we maintaining this huge Path List for every RelOptInfo
structure if we only need the cheapest? Why not store only the cheapest
plan, instead of generating all unique plans, then using only the
cheapest?

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026