On Wed, May 9, 2012 at 5:45 PM, Claudio Freire <klaussfreire@xxxxxxxxx> wrote: > On Wed, May 9, 2012 at 12:41 PM, Robert Klemme > <shortcutter@xxxxxxxxxxxxxx> 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. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
