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: http://www.postgresql.org/mailpref/pgsql-hackers
