Re: Synchronous Log Shipping Replication
От | Simon Riggs |
---|---|
Тема | Re: Synchronous Log Shipping Replication |
Дата | |
Msg-id | 1220962114.3913.447.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Synchronous Log Shipping Replication (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
On Tue, 2008-09-09 at 12:54 +0300, Heikki Linnakangas wrote: > Note that we already have the logic to flush all pending commit > records at once. But only when you can grab WALInsertLock when flushing. If you look at the way I suggested, it does not rely upon that lock being available. So it is both responsive in low write rate conditions and yet efficient in high write rate conditions and does not require we specify a wait time. IMHO the idea of a wait time is a confusion that comes from using a simple example (with respect). If we imagine the example slightly differently you'll see a different answer: High write rate: A stream of commits come so fast that by the time a write completes there are always > 1 backends waiting to commit again. In that case, there is never any need to wait because the arrival pattern requries us to issues writes as quickly as we can. Medium write rate: Commits occur relatively frequently, so that the mean commits/flush is in the range 0.5 - 1. In this case, we can get better I/O efficiency by introducing waits. But note that a wait is risky, and at some point we may wait without another commit arriving. In this case, if the disk can keep up with the write rate, why would we want to improve I/O efficiency? There's no a priori way of calculating a useful wait time, so waiting is always a risk. Why would we risk damage to our response times when the disk can keep up with write rate? So for me, introducing a wait is something you might want to consider in medium rate conditions. Anything more or less than that and a wait is useless. So optimising for the case where the arrival rate is within a certain fairly tight range seems not worthwhile. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: