On 19/05/10 00:37, Simon Riggs wrote:
> On Tue, 2010-05-18 at 17:25 -0400, Heikki Linnakangas wrote:
>> On 18/05/10 17:17, Simon Riggs wrote:
>>> There's no reason that the buffer size we use for XLogRead() should be
>>> the same as the send buffer, if you're worried about that. My point is
>>> that pq_putmessage contains internal flushes so at the libpq level you
>>> gain nothing by big batches. The read() will be buffered anyway with
>>> readahead so not sure what the issue is. We'll have to do this for sync
>>> rep anyway, so what's the big deal? Just do it now, once. Do we really
>>> want 9.1 code to differ here?
>>
>> Do what? What exactly is it that you want instead, then?
>
> Read and write smaller messages, so the latency is minimised. Libpq will
> send in 8192 byte packets, so writing anything larger gains nothing when
> the WAL data is also chunked at exactly the same size.
Committed with chunk size of 128 kB. I hope that's a reasonable
compromise, in the absence of any performance test data either way.
I'm weary of setting it as low as 8k, as there is some per-message
overhead. Some of that could be avoided by rearranging the loops so that
the ps display is not updated at every message as you suggested, but I
don't feel doing any extra rearrangements at this point. It would not be
hard, but it also certainly wouldn't make the code simpler.
I believe in practice 128kB is just as good as 8k from the
responsiveness point of view. If a standby is not responding, walsender
will be stuck trying to send no matter what the block size is. If it
responding, no matter how slowly, 128kB should get transferred pretty
quickly.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
