Re: Quorum commit for multiple synchronous replication.

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Petr Jelinek <petr@2ndquadrant.com>, Vik Fearing <vik@2ndquadrant.fr>, Simon Riggs <simon@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-12-08T00:07:28Z
Lists: 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


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Set the priorities of all quorum synchronous standbys to 1.

  2. Improve documentation and comment for quorum-based sync replication.