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. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
