On Thursday 16 July 2009 19:22:30 Robert Haas wrote: > On Thu, Jul 16, 2009 at 11:32 AM, Tom Lane<t...@sss.pgh.pa.us> wrote: > > I wrote: > >> If I set both collapse_limit variables to very high values (I used 999), > >> it takes ... um ... not sure; I gave up waiting after half an hour. > >> I also tried with geqo_effort reduced to the minimum of 1, but that > >> didn't produce a plan in reasonable time either (I gave up after ten > >> minutes). > > > > After I gave up letting the machine be idle to get a fair timing, > > I turned on oprofile monitoring. It looks a bit interesting: > That is interesting, but there's not really enough detail here to see > what is going on. I'm more interested in what the high-level > functions are doing that's causing these guys to be called so many > times. As Greg says, if the planning time curve for GEQO isn't better > than the one for the standard planner, it's the epitome of pointless. It is not the actual genetic searching I now found out (or more precisely, read the trace correctly).
At the start of the query GEQO fills a pool with random paths through the searchspace. Unfortunately a random path is not very likely to succeed. So it checks and checks and... Thats why that problem is not visible with a simple join out of 100 or so tables - all paths are valid there... Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
