On Thu, Jul 16, 2009 at 11:32 AM, Tom Lane<tgl@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.
> So maybe a redesign of the equivalence-class joinclause mechanism is in
> order. Still, this is unlikely to fix the fundamental issue that the
> time for large join problems grows nonlinearly.
Nonlinear is one thing, but this looks more like exponential. I
understand that the standard planner is exponential; GEQO should not
be.
...Robert