Re: Possible planner bug/regression introduced in 8.2.5
От | Tom Lane |
---|---|
Тема | Re: Possible planner bug/regression introduced in 8.2.5 |
Дата | |
Msg-id | 17292.1193408942@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Possible planner bug/regression introduced in 8.2.5 (Jakub Ouhrabka <kuba@comgate.cz>) |
Ответы |
Re: Possible planner bug/regression introduced in 8.2.5
|
Список | pgsql-bugs |
Jakub Ouhrabka <kuba@comgate.cz> writes: > We did some test today with patched 8.2.5. For some cases it is ok but > for large ones it is still taking quite a big time (e.g. for 23 joins is > the planning time 107s). Maybe there's no regression from 8.2.4 - we'll > do the tests against 8.2.4 on Monday - it's not usual for us to run with > geqo switched off and we don't monitor the planning time - the total > runtime for these queries is in minutes so we don't know were the time > is spent. Yeah, I was afraid that might happen. In the test case you sent, if the first LEFT JOIN is changed to RIGHT JOIN then the runtime goes right back up, because then it actually is the case make_outerjoininfo is looking for where the two outer joins can't be reordered. So you 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. regards, tom lane
В списке pgsql-bugs по дате отправления: