From: | Oskari Saarenmaa <os(at)ohmu(dot)fi> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #8470: 9.3 locking/subtransaction performance regression |
Date: | 2014-01-14 12:43:05 |
Message-ID: | 20140114124305.GA28072@saarenmaa.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Thanks for looking at this and sorry about the late reply, I finally got
around to testing your latest patch.
20.12.2013 22:47, Alvaro Herrera kirjoitti:
>> Removing the BEGIN/EXCEPTION/END block and just doing a 'SELECT FOR
>> UPDATE' for a suitable row is significantly slower in 9.3.0 (314.765 ms
>> vs 118.894 ms on 9.2.4). A 'SELECT' without a FOR UPDATE and
>> BEGIN/EXCEPTION/END has the same performance on 9.2.4 and 9.3.0.
>
> I have come up with the attached patch. As far as I can tell it
> restores performance roughly to the level of 9.2 for this test case;
> could you please try it out and see if it fixes things for you? It'd be
> particularly good if you can check not only the test case you submitted
> but also the one that made you explore this in the first place.
I didn't try this patch, but I built today's REL9_3_STABLE with the patch
from your mail on the 31st of Dec
(http://github.com/saaros/postgres/tree/alvaro-multixact-optimize-9.3) and
ran the older version of my appliaction's test suite which has a case that
times out after 3 minutes with unpatched 9.3. With the current patch the
test case successfully completes in ~20 seconds which is a major improvement
although it's still slower than 9.2 It also passes all other test cases in
my test suite.
Do you think it'll make it to 9.3.3?
Thanks,
Oskari
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-01-14 13:09:09 | Re: BUG #8470: 9.3 locking/subtransaction performance regression |
Previous Message | valgog | 2014-01-14 10:32:19 | BUG #8830: Query with a subquery failes to execute if this subquery does not contain references to own table |