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

From Robert Haas
Subject Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZEto max_wal_send
Date
Msg-id CA+Tgmoa-QucPwCYu9cdJZfBtERzQv-ZNSPm92kFYyOBgOCWjDw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send  (Jonathon Nelson <jdnelson@dyn.com>)
List pgsql-hackers
On Mon, Jan 9, 2017 at 4:27 PM, Jonathon Nelson <jdnelson@dyn.com> wrote:
> [I have not done a rigid analysis, here, but...]
>
> I *think* libpq is the culprit here.
>
> walsender says "Hey, libpq - please send (up to) 128KB of data!" and doesn't
> "return" until it's "sent". Then it sends more.  Regardless of the
> underlying cause (nagle, tcp congestion control algorithms, umpteen
> different combos of hardware and settings, etc..) in almost every test I saw
> improvement (usually quite a bit). This was most easily observable with high
> bandwidth-delay product links, but my time in the lab is somewhat limited.

This seems plausible to me.  If it takes X amount of time for the
upper layers to put Y amount of data into libpq's buffers, that
imposes some limit on overall throughput.

I mean, is it not sufficient to know that the performance improvement
is happening?  If it's happening, there's an explanation for why it's
happening.

It would be good if somebody else could try to reproduce these results, though.

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



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: [HACKERS] PATCH: recursive json_populate_record()
Next
From: Alvaro Herrera
Date:
Subject: [HACKERS] Re: [COMMITTERS] pgsql: Remove objname/objargs split for referringto objects