Re: Quorum commit for multiple synchronous replication. - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Quorum commit for multiple synchronous replication.
Date
Msg-id 20161207.144938.176033734.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Quorum commit for multiple synchronous replication.  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Quorum commit for multiple synchronous replication.  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
At Wed, 7 Dec 2016 13:26:38 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in
<CAB7nPqSyfsg=gHeqgXyzP0iGWvdyrXqnG-UENzfueaU=2m5-zg@mail.gmail.com>
> On Wed, Dec 7, 2016 at 12:32 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> > So, isn't it better to compare the performance of some algorithms and
> > confirm which is the best for quorum commit? Since this code is hot, i.e.,
> > can be very frequently executed, I'd like to avoid waste of cycle as much
> > as possible.
> 
> It seems to me that it would be simple enough to write a script to do
> that to avoid any other noise: allocate an array with N random
> elements, and fetch the M-th element from it after applying a sort
> method. I highly doubt that you'd see much difference with a low
> number of elements, now if you scale at a thousand standbys in a
> quorum set you may surely see something :*)
> Anybody willing to try out?


Aside from measurement of the two sorting methods, I'd like to
point out that quorum commit basically doesn't need
sorting. Counting comforming santdbys while scanning the
walsender(receiver) LSN list comparing with the target LSN is
O(n). Small refactoring of SyncRerpGetOldestSyncRecPtr would
enough to do that.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center





pgsql-hackers by date:

Previous
From: Andreas Seltenreich
Date:
Subject: Short reads in hash indexes (was: [sqlsmith] Failed assertion in _hash_splitbucket_guts)
Next
From: Craig Ringer
Date:
Subject: Re: Logical decoding on standby