Re: [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

From: Greg Stark <stark(at)mit(dot)edu>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Jonathon Nelson <jdnelson(at)dyn(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send
Date: 2017-01-08 17:26:26
Message-ID: CAM-w4HPSnDHib3PdU_K04gm3f3RoPX7VfbgyX4zhdwTxL0ByAw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5 January 2017 at 19:01, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2017-01-08 17:36:29 Re: [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send
Previous Message Tom Lane 2017-01-08 17:25:07 Re: Increase pltcl test coverage