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

From Robert Haas
Subject Re: Quorum commit for multiple synchronous replication.
Date
Msg-id CA+TgmoZDRs0rhEH8Q6OPwtEfmyLH41+v95k+t-Sq3oMqSvcxaw@mail.gmail.com
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.
List pgsql-hackers
On Tue, Dec 6, 2016 at 11:26 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> 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?

You could do that, but first I would code up the simplest, cleanest
algorithm you can think of and see if it even shows up in a 'perf'
profile.  Microbenchmarking is probably overkill here unless a problem
is visible on macrobenchmarks.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Back-patch use of unnamed POSIX semaphores for Linux?
Next
From: Tom Lane
Date:
Subject: Re: varlena beyond 1GB and matrix