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
