Re: GUC-ify walsender MAX_SEND_SIZE constant - Mailing list pgsql-hackers

From Majid Garoosi
Subject Re: GUC-ify walsender MAX_SEND_SIZE constant
Date
Msg-id CAFWczPt7ZKN5YsbQ+GoMq=fM_4xJduOiVAWNak1F-u3QgfNO0Q@mail.gmail.com
Whole thread Raw
In response to Re: GUC-ify walsender MAX_SEND_SIZE constant  (Michael Paquier <michael@paquier.xyz>)
Responses Re: GUC-ify walsender MAX_SEND_SIZE constant
List pgsql-hackers
Hey folks,

Any news, comments, etc. about this thread?

Best regards
Majid Garoosi

On Mon, 12 Feb 2024 at 01:10, Michael Paquier <michael@paquier.xyz> wrote:
On Sun, Feb 11, 2024 at 04:32:20PM +0330, Majid Garoosi wrote:
> On Fri, 9 Feb 2024 at 22:33, Andres Freund <andres@anarazel.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

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: promotion related handling in pg_sync_replication_slots()
Next
From: Masahiko Sawada
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation