On Wed, May 9, 2012 at 12:03 PM, Robert Klemme
> On Wed, May 9, 2012 at 5:45 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
>> On Wed, May 9, 2012 at 12:41 PM, Robert Klemme
>> <shortcutter(at)googlemail(dot)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."
>> 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
> 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
In response to
pgsql-performance by date
|Next:||From: MauMau||Date: 2012-05-09 22:34:04|
|Subject: Re: Could synchronous streaming replication really degrade the performance of the primary?|
|Previous:||From: Robert Klemme||Date: 2012-05-09 17:03:14|
|Subject: Re: Could synchronous streaming replication really degrade
the performance of the primary?|