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.
--
Michael