On Sat, Dec 19, 2015 at 3:19 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > Hi, > > On 11/06/2015 02:09 AM, Tomas Vondra wrote: >> >> Hi, >> >> On 11/06/2015 01:05 AM, Jeff Janes wrote: >>> >>> On Thu, Nov 5, 2015 at 3:50 PM, Tomas Vondra >>> <tomas.von...@2ndquadrant.com> wrote: >> >> ... >>>> >>>> >>>> I can do that - I see there are three patches in the two threads: >>>> >>>> 1) gin_pending_lwlock.patch (Jeff Janes) >>>> 2) gin_pending_pagelock.patch (Jeff Janes) >>>> 3) gin_alone_cleanup-2.patch (Teodor Sigaev) >>>> >>>> Should I test all of them? Or is (1) obsoleted by (2) for example? >>> >>> >>> 1 is obsolete. Either 2 or 3 should fix the bug, provided this is the >>> bug you are seeing. They have different performance side effects, but >>> as far as fixing the bug they should be equivalent. >> >> >> OK, I'll do testing with those two patches then, and I'll also note the >> performance difference (the data load was very stable). Of course, it's >> just one particular workload. >> >> I'll post an update after the weekend. > > > I've finally managed to test the two patches. Sorry for the delay. > > I've repeated the workload on 9.5, 9.6 and 9.6 with (1) or (2), looking for > lockups or data corruption. I've also measured duration of the script, to > see what's the impact on performance. The configuration (shared_buffers, > work_mem ...) was exactly the same in all cases. > > 9.5 : runtime ~1380 seconds > 9.6 : runtime ~1380 seconds (but lockups and data corruption) > 9.6+(1) : runtime ~1380 seconds > 9.6+(2) : runtime ~1290 seconds > > So both patches seem to do the trick, but (2) is faster. Not sure if this is > expected. (BTW all the results are without asserts enabled).
Do you know what the size of the pending list was at the end of each test? I think last one may be faster because it left a large mess behind that someone needs to clean up later. Also, do you have the final size of the indexes in each case? Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers