Re: Could synchronous streaming replication really degrade the performance of the primary?

On Wed, May 9, 2012 at 12:03 PM, Robert Klemme
<shortcutter(at)googlemail(dot)com> wrote:
> 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."
>>> 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