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
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 |