On Wed, May 9, 2012 at 12:03 PM, Robert Klemme <shortcut...@googlemail.com> wrote: > On Wed, May 9, 2012 at 5:45 PM, Claudio Freire <klaussfre...@gmail.com> wrote: >> On Wed, May 9, 2012 at 12:41 PM, Robert Klemme >> <shortcut...@googlemail.com> wrote: >>> I am not sure whether the replicant can be triggered to commit to disk >>> before the commit to disk on the master has succeeded; if that was the >>> case there would be true serialization => 50%. >>> >>> This sounds like it could actually be the case (note the "after it >>> commits"): >>> "When synchronous replication is requested the transaction will wait >>> after it commits until it receives confirmation that the transfer has >>> been successful." >>> http://wiki.postgresql.org/wiki/Synchronous_replication >> >> That should only happen for very short transactions. >> IIRC, WAL records can be sent to the slaves before the transaction in >> the master commits, so bigger transactions would see higher >> parallelism. > > I considered that as well. But the question is: when are they written > to disk in the slave? If they are in buffer cache until data is > synched to disk then you only gain a bit of advantage by earlier > sending (i.e. network latency). Assuming a high bandwidth and low > latency network (which you want to have in this case anyway) that gain > is probably not big compared to the time it takes to ensure WAL is > written to disk. I do not know implementation details but *if* the > server triggers sync only after its own sync has succeeded *then* you > basically have serialization and you need to wait twice the time. > > For small TX OTOH network overhead might relatively large compared to > WAL IO (for example with a battery backed cache in the controller) > that it shows. Since we do not know the test cases which lead to the > 50% statement we can probably only speculate. Ultimately each > individual setup and workload has to be tested.
yeah. note the upcoming 9.2 synchronous_commit=remote_write setting is intended to improve this situation by letting the transaction go a bit earlier -- the slave basically only has to acknowledge receipt of the data. merlin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
