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