From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Majid Garoosi <amoomajid99(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: GUC-ify walsender MAX_SEND_SIZE constant |
Date: | 2024-02-09 19:03:46 |
Message-ID: | 20240209190346.22fwj4xb67cmh3io@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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?
I don't think we should add configuration parameters without at least some
demonstration of practical gains, otherwise we'll end up with hundreds of
never-useful config options.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2024-02-09 19:23:46 | Re: [PATCH] Add native windows on arm64 support |
Previous Message | Andrey Borodin | 2024-02-09 19:02:08 | Re: glibc qsort() vulnerability |