From: | Majid Garoosi <amoomajid99(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: GUC-ify walsender MAX_SEND_SIZE constant |
Date: | 2024-02-11 13:02:20 |
Message-ID: | CAFWczPtj5XFf6bar-NPmgc8uvavooNdyq1q1zVyzknA=87inVA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Andres,
On Fri, 9 Feb 2024 at 22:33, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2024-01-19 23:04:50 +0330, Majid Garoosi wrote:
> > Following is the description which is also written in the commit message:
> > MAX_SEND_SIZE parameter was used in WALSender to limit maximum size of
> > a WAL data packet sent to a WALReceiver during replication. Although
> > its default value (128kB) was a reasonable value, it was written in
> > 2010. Since the hardwares have changed a lot since then, a PostgreSQL
> > user might need to customize this value.
> > For example, if a database's disk has a high bandwidth and a high
> > latency at the same time, it makes more sense to read bigger chunks of
> > data from disk in each iteration. One example of such disks is a remote
> > disk. (e.g. an RBD volume)
>
> 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.
Best
Majid
From | Date | Subject | |
---|---|---|---|
Next Message | Zhijie Hou (Fujitsu) | 2024-02-11 13:23:19 | RE: Synchronizing slots from primary to standby |
Previous Message | Erik Wienhold | 2024-02-11 01:52:56 | Re: Patch: Add parse_type Function |