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.

Still digging into the optimizer, but if you want some real eye-opening
stuff, set OPTIMIZER_DEBUG and look in the postmaster log. A six-table
join generates 55k lines of debug info, very nicely formatted. It shows
what we are up against.

--
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