Re: Possible planner bug/regression introduced in 8.2.5

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jakub Ouhrabka <kuba(at)comgate(dot)cz>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Possible planner bug/regression introduced in 8.2.5
Date: 2007-10-26 14:29:02
Message-ID: 17292.1193408942@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Jakub Ouhrabka <kuba(at)comgate(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2007-10-26 14:31:57 Re: BUG #3699: Fails to compile DTrace Support
Previous Message Gergely Bor 2007-10-26 14:17:43 Re: Yet another problem with ILIKE and UTF-8