On Wed, May 9, 2012 at 5:45 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
> On Wed, May 9, 2012 at 12:41 PM, Robert Klemme
> <shortcutter@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.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/