Re: Synchronous replication - patch status inquiry - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Synchronous replication - patch status inquiry
Date
Msg-id AANLkTikCMi8o2bq4JhRVVGXnmx0vhTr75bPfo6feurTZ@mail.gmail.com
Whole thread Raw
In response to Re: Synchronous replication - patch status inquiry  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Mon, Sep 6, 2010 at 10:14 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> That doesn't really answer the question: *when* does standby send back
>> the acknowledgment?
>
> I think you should explain when you think this happens in your proposal.
>
> Are you saying that you think the standby should send back one message
> for every transaction? That you do not think we should buffer the return
> messages?

That's certainly what I was assuming - I can't speak for anyone else, of course.

> You seem to be proposing a design for responsiveness to a single
> transaction, not for overall throughput. That's certainly a design
> choice, but it wouldn't be my recommendation that we did that.

Gee, I thought that if we tried to buffer the messages, you'd end up
*reducing* overall throughput.  Suppose we have a busy system.  The
number of simultaneous transactions in flight is limited by
max_connections.  So it seems to me that if each transaction takes X%
longer to commit, then throughput will be reduced by X%.  And as
you've said, batching responses will make individual transactions less
responsive.  The corresponding advantage of batching the responses is
that you reduce consumption of network bandwidth, but I don't think
that's normally where the bottleneck will be.

Of course, you might be able to opportunistically combine messages, if
additional transactions become ready to acknowledge after the first
one has become ready but before the acknowledgement has actually been
sent.  But waiting to try to increase the batch size doesn't seem
right.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: Rewrite, normal execution vs. EXPLAIN ANALYZE
Next
From: Robert Haas
Date:
Subject: Re: Synchronization levels in SR