Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZEto max_wal_send

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZEto max_wal_send
Дата
Msg-id CA+Tgmoa-QucPwCYu9cdJZfBtERzQv-ZNSPm92kFYyOBgOCWjDw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send  (Jonathon Nelson <jdnelson@dyn.com>)
Список 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 по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: [HACKERS] PATCH: recursive json_populate_record()
Следующее
От: Alvaro Herrera
Дата:
Сообщение: [HACKERS] Re: [COMMITTERS] pgsql: Remove objname/objargs split for referringto objects