From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: GIN data corruption bug(s) in 9.6devel |
Date: | 2016-04-06 16:52:14 |
Message-ID: | 57053EBE.1050904@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2016-04-06 16:55:41 | Re: insufficient qualification of some objects in dump files |
Previous Message | Teodor Sigaev | 2016-04-06 16:28:53 | Re: [PATH] Jsonb, insert a new value into an array at arbitrary position |