| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, fazool mein <fazoolmein(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Synchronous replication - patch status inquiry |
| Date: | 2010-09-07 10:11:38 |
| Message-ID: | 4C860FDA.9010408@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 07/09/10 12:47, Simon Riggs wrote:
> The WAL is sent from master to standby in 8192 byte chunks, frequently
> including multiple commits. From standby, one reply per chunk. If we
> need to wait for apply while nothing else is received, we do.
Ok, thank you. The obvious performance problem is that even if you
define a transaction to use synchronization level 'recv', and there's no
other concurrent transactions running, you actually need to wait until
it's applied. If you have only one client, there is no difference
between the levels, you always get the same performance hit you get with
'apply'. With more clients, you get some benefit, but there's still
plenty of delays compared to the optimum.
Also remember that there can be a very big gap between when a record is
fsync'd and when it's applied, if the recovery needs to wait for a hot
standby transaction to finish.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2010-09-07 10:24:37 | Re: Synchronous replication - patch status inquiry |
| Previous Message | Simon Riggs | 2010-09-07 09:47:54 | Re: Synchronous replication - patch status inquiry |