Re: Proposal: "Causal reads" mode for load balancing reads without stale data - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proposal: "Causal reads" mode for load balancing reads without stale data
Date
Msg-id CA+Tgmoaw=foHzt2ZH-YG0AEgiATeQNA3NN8Eyrq-_S5N9Gc3BA@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: "Causal reads" mode for load balancing reads without stale data  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Proposal: "Causal reads" mode for load balancing reads without stale data
List pgsql-hackers
On Wed, Mar 23, 2016 at 8:43 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Mar 23, 2016 at 8:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Mar 23, 2016 at 7:34 AM, Thomas Munro
>> <thomas.munro@enterprisedb.com> wrote:
>>> synchronous_commit    TPS
>>> ==================== ====
>>> off                  9234
>>> local                1223
>>> remote_write          907
>>> on                    587
>>> remote_apply          555
>>>
>>> synchronous_commit    TPS
>>> ==================== ====
>>> off                  3937
>>> local                1984
>>> remote_write         1701
>>> on                   1373
>>> remote_apply         1349
>>
>> Hmm, so "remote_apply" is barely more expensive than "on".  That's encouraging.
>
> Indeed, interesting. This is perhaps proving that just having the
> possibility to have remote_apply (with feedback messages managed by
> signals, which is the best thing proposed for this release) is what we
> need to ensure the consistency of reads across nodes, and what would
> satisfy most of the user's requirements. Getting a slightly lower TPS
> may be worth the cost for some users if they can ensure that reads
> across nodes are accessible after a local commit, and there is no need
> to have an error management layer at application level to take care of
> errors caused by causal read timeouts.

Well, I wouldn't go that far.  It seems pretty clear that remote_apply
by itself is useful - I can't imagine anybody seriously arguing the
contrary, whatever they think of this implementation.  My view,
though, is that by itself that's pretty limiting: you can only have
one standby, and if that standby falls over then you lose
availability.  Causal reads fixes both of those problems - admittedly
that requires some knowledge in the application or the pooler, but
it's no worse than SSI in that regard.  Still, half a loaf is better
than none, and I imagine even just getting remote_apply would make a
few people quite happy.

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



pgsql-hackers by date:

Previous
From: Andreas Karlsson
Date:
Subject: Re: [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend
Next
From: Eduardo Morras
Date:
Subject: Re: [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend