>> ...probably have some cases like that in your real application. But I'd
>> expect 8.2.4 to be equally slow because it also contains the code that
>> is slow in that scenario. I'm hoping to get some time today to think
>> about how that could be fixed.
> Please try the attached patch (in addition to the one I sent earlier).
I can confirm that now there is no regression between 8.2.4 and
I've also tried your last patch but still for some queries there is long
planning time, e.g. more than 30s on a fast machine for query with 14
regularly JOINed tables plus 8 tables are LEFT OUTER JOINed (all normal
joins are followed by all outer joins). All joins are constrained on
pk/fk. Should this case run faster or is it simply too much for
geqo=off? Shall I prepare a test case?
In response to
pgsql-bugs by date
|Next:||From: Scott Bailey||Date: 2007-10-29 15:44:52|
|Subject: BUG #3706: ecpg regression: "MOVE FORWARD"|
|Previous:||From: Tom Lane||Date: 2007-10-28 22:34:36|
|Subject: Re: BUG #3362: xlog corruption just after initdb on irix |