Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send
Date
Msg-id CAM-w4HPSnDHib3PdU_K04gm3f3RoPX7VfbgyX4zhdwTxL0ByAw@mail.gmail.com
Whole thread Raw
In response to [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send  (Jonathon Nelson <jdnelson@dyn.com>)
Responses Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On 5 January 2017 at 19:01, Andres Freund <andres@anarazel.de> wrote:
> That's a bit odd - shouldn't the OS network stack take care of this in
> both cases?  I mean either is too big for TCP packets (including jumbo
> frames).  What type of OS and network is involved here?

2x may be plausible. The first 128k goes out, then the rest queues up
until the first ack comes back. Then the next 128kB goes out again
without waiting... I think this is what Nagle is supposed to actually
address but either it may be off by default these days or our usage
pattern may be defeating it in some way.

-- 
greg



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Increase pltcl test coverage
Next
From: Greg Stark
Date:
Subject: Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send