On Wed, 2010-09-01 at 08:33 +0300, Heikki Linnakangas wrote:
> On 01/09/10 04:02, Robert Haas wrote:
> > See the thread on interruptible sleeps. The problem
> > right now is that there are some polling loops that act to throttle
> > the maximum rate at which a node doing sync rep can make forward
> > progress, independent of the capabilities of the hardware.
>
> To be precise, the polling doesn't affect the "bandwidth" the
> replication can handle, but it introduces a delay wh
We're sending the WAL data in batches. We can't really escape from the
fact that we're effectively using group commit when we use synch rep.
That will necessarily increase delay and require more sessions to get
same throughput.
> > Those need
> > to be replaced with a system that doesn't inject unnecessary delays
> > into the process, which is what Heikki is working on.
>
> Right.
> Once we're done with that, all the big questions are still left. How to
> configure it? What does synchronous replication mean, when is a
> transaction acknowledged as committed? What to do if a standby server
> dies and never acknowledges a commit? All these issues have been
> discussed, but there is no consensus yet.
That sounds an awful lot like performance tuning first and the feature
additions last.
And if you're in the middle of performance tuning, surely some objective
performance tests would help us, no?
IMHO we should be concentrating on how to add the next features because
its clear to me that if you do things in the wrong order you'll be
wasting time. And we don't have much of that, ever.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services
