"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>> Those patches are certainly already in the 8.2 CVS branch, so your
>> question seems to mean "are we going to push 8.2.6 immediately to fix
>> this". My vote would be no --- 8.2.5 is less than six weeks old and
> I suppose ca
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Tom Lane wrote:
>> Please try the attached patch (in addition to the one I sent earlier).
> This is biting us too, quite badly. Any chance this can get pushed into a
> 8.2.6?
> Those patches are certainly already in the 8.2 CVS branch, so y
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Please try the attached patch (in addition to the one I sent earlier).
> This is biting us too, quite badly. Any chance this can get pushed into a
> 8.2.6?
Those patches are certainly already in the 8.2 CVS branch, so your
qu
Jakub Ouhrabka <[EMAIL PROTECTED]> writes:
>> By "last patch" you mean
>> http://archives.postgresql.org/pgsql-committers/2007-10/msg00409.php
> Sorry for confusion, I meant this one:
> http://archives.postgresql.org/pgsql-bugs/2007-10/msg00217.php
> Is it the same as the commited one?
Yeah, shou
By "last patch" you mean
http://archives.postgresql.org/pgsql-committers/2007-10/msg00409.php
?
Sorry for confusion, I meant this one:
http://archives.postgresql.org/pgsql-bugs/2007-10/msg00217.php
Is it the same as the commited one?
If so that's about as fast as it's likely to get. 22
Jakub Ouhrabka <[EMAIL PROTECTED]> writes:
> 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 oute
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane wrote:
> Please try the attached patch (in addition to the one I sent earlier).
This is biting us too, quite badly. Any chance this can get pushed into a
8.2.6?
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 20071029
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 additio
I wrote:
> ...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 ad
Jakub Ouhrabka <[EMAIL PROTECTED]> 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
Hi Tom,
Hmm. I think there are two different bugs involved here. One is fixed
by the attached patch, and it masks the performance problem on your test
case, but I wonder whether it will be enough for your real application.
Can you try this and see if it fixes 8.2.5 for you?
many thanks for t
Jakub Ouhrabka <[EMAIL PROTECTED]> writes:
> preparing the test case was easier than I expected. It's attached. Fast
> planning on 8.2.4, very slow on 8.2.5.
Hmm. I think there are two different bugs involved here. One is fixed
by the attached patch, and it masks the performance problem on your
Hi Tom,
> Either poke into the code yourself, or submit a self-contained test
> case (the query alone does not a test case make). I can't offhand
> think of a reason for 8.2.5 to be slower than 8.2.4 ...
preparing the test case was easier than I expected. It's attached. Fast
planning on 8.2.4,
Jakub Ouhrabka <[EMAIL PROTECTED]> writes:
> What can I do to help to debug it?
Either poke into the code yourself, or submit a self-contained test case
(the query alone does not a test case make). I can't offhand think of a
reason for 8.2.5 to be slower than 8.2.4 ...
re
Hi Tom,
I tried to simplify the query even more and now I have query which on
8.2.4 is planned instantly and on 8.2.5 takes cca 8 seconds.
Are you sure you were using the same planner parameters (particularly
join_collapse_limit and the geqo threshold) in both cases?
thanks for the reply.
Y
Jakub Ouhrabka <[EMAIL PROTECTED]> writes:
> I tried to simplify the query even more and now I have query which on
> 8.2.4 is planned instantly and on 8.2.5 takes cca 8 seconds.
Are you sure you were using the same planner parameters (particularly
join_collapse_limit and the geqo threshold) in bo
16 matches
Mail list logo
