| 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: | Postg스포츠 토토 사이트SQL |
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
| 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 |