Re: Possible planner bug/regression introduced in 8.2.5 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Possible planner bug/regression introduced in 8.2.5
Date
Msg-id 17292.1193408942@sss.pgh.pa.us
Whole thread Raw
In response to Re: Possible planner bug/regression introduced in 8.2.5  (Jakub Ouhrabka <kuba@comgate.cz>)
Responses Re: Possible planner bug/regression introduced in 8.2.5
List 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 by date:

Previous
From: "Gergely Bor"
Date:
Subject: Re: Yet another problem with ILIKE and UTF-8
Next
From: Tom Lane
Date:
Subject: Re: BUG #3699: Fails to compile DTrace Support