On Wed, Mar 23, 2016 at 8:43 AM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Wed, Mar 23, 2016 at 8:39 PM, Robert Haas <robertmh...@gmail.com> wrote:
>> On Wed, Mar 23, 2016 at 7:34 AM, Thomas Munro
>> <thomas.mu...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to