Re: GIN data corruption bug(s) in 9.6devel - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: GIN data corruption bug(s) in 9.6devel
Date
Msg-id 57053EBE.1050904@sigaev.ru
Whole thread Raw
In response to Re: GIN data corruption bug(s) in 9.6devel  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: GIN data corruption bug(s) in 9.6devel  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
> I've tested the v2, v3 and v3.1 of the patch, to see if there are any
> differences. The v2 no longer applies, so I tested it on ee943004. The following
> table shows the total duration of the data load, and also sizes of the two GIN
> indexes.
>
>             duration (sec)          subject          body
>    ---------------------------------------------------------------
>    v2          1290                 23 MB           684 MB
>    v3          1360                 24 MB           487 MB
>    v3.1        1360                 24 MB           488 MB
Thank you very much.

Hmm. v3 is a just rebased version of v2, v3.1 hasn't unlock/lock cycle during 
cleanup, just to become similar to Jeff's pending lock patch. In theory, v2 and 
v3 should be very close, v3.1 should be close to pending_lock.

I'm inclining to push v3.1 as one of two winners by size/performance and, unlike 
to pending lock patch, it doesn't change an internal logic of lock machinery.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 



pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: [PATH] Jsonb, insert a new value into an array at arbitrary position
Next
From: Peter Eisentraut
Date:
Subject: Re: insufficient qualification of some objects in dump files