Re: Proposal: "Causal reads" mode for load balancing reads without stale data

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Thom Brown <thom(at)linux(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: "Causal reads" mode for load balancing reads without stale data
Date: 2016-03-23 14:32:11
Message-ID: CA+Tgmoaw=foHzt2ZH-YG0AEgiATeQNA3NN8Eyrq-_S5N9Gc3BA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 23, 2016 at 8:43 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Wed, Mar 23, 2016 at 8:39 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Mar 23, 2016 at 7:34 AM, Thomas Munro
>> <thomas(dot)munro(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Eduardo Morras 2016-03-23 14:37:25 Re: [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend
Previous Message Andreas Karlsson 2016-03-23 14:23:52 Re: [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend