| From: | Jakub Ouhrabka <kuba(at)comgate(dot)cz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: Possible planner bug/regression introduced in 8.2.5 |
| Date: | 2007-10-29 15:27:48 |
| Message-ID: | 4725FBF4.1080403@comgate.cz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi Tom,
>> ...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
8.2.5+one-line-patch.
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?
Thanks,
Kuba
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Bailey | 2007-10-29 15:44:52 | BUG #3706: ecpg regression: "MOVE FORWARD" |
| Previous Message | Tom Lane | 2007-10-28 22:34:36 | Re: BUG #3362: xlog corruption just after initdb on irix |