Re: GUC-ify walsender MAX_SEND_SIZE constant

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Majid Garoosi <amoomajid99(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Subject: Re: GUC-ify walsender MAX_SEND_SIZE constant
Date: 2024-02-12 00:10:45
Message-ID: ZcliBT1AujeBvQQX@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 11, 2024 at 04:32:20PM +0330, Majid Garoosi wrote:
> On Fri, 9 Feb 2024 at 22:33, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> The way we read the WAL data is perfectly prefetchable by the the OS, so I
>> wouldn't really expect gains here. Have you actually been able to see a
>> performance benefit by increasing MAX_SEND_SIZE?
>
> Yes, I have seen a huge performance jump. Take a look at here
> <https://www.postgresql.org/message-id/CAFWczPvi_5FWH%2BJTqkWbi%2Bw83hy%3DMYg%3D2hKK0%3DJZBe9%3DhTpE4w%40mail.gmail.com>
> for
> more info.

Yes, I can get the idea that grouping more replication messages in
one shot can be beneficial in some cases while being
environment-dependent, though I also get the point that we cannot
simply GUC-ify everything either. I'm OK with this one at the end,
because it is not performance critical.

Note that it got lowered to the current value in ea5516081dcb to make
it more responsive, while being half a WAL segment in 40f908bdcdc7
when WAL senders have been introduced in 2010. I cannot pinpoint the
exact thread that led to this change, but I'm adding Fujii-san and
Heikki in CC for comments.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2024-02-12 01:22:24 Re: Printing backtrace of postgres processes
Previous Message jian he 2024-02-12 00:00:00 Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row