GUCifying MAX_WAL_SEND

From: Majid Garoosi <amoomajid99(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: GUCifying MAX_WAL_SEND
Date: 2024-01-10 21:45:48
Message-ID: CAFWczPvi_5FWH+JTqkWbi+w83hy=MYg=2hKK0=JZBe9=hTpE4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello all,

*TL; DR*
There has been a discussion about GUCifying the MAX_WAL_SEND constant in
walsender.c in here <https://commitfest.postgresql.org/13/958/> nearly 7
years ago, but resulting in nothing in the end. Today, I found out the
configurability of this parameter can be very helpful. So, I want to submit
a patch for it, but I also want to know your comments before then.

What is MAX_WAL_SEND?
It's the maximum size of WAL records that walsender reads from the disk and
then sends to the standby servers. Its current value is hardcoded as
XLOG_BLCKSZ * 16, which is 128KiB (8KiB * 16) by default.

Why do I think it can be beneficial to GUCify it?
We use Postgres in K8s along with RBD disks. Today, I found out that
because we use remote disks, it's better to read bigger chunks of data from
the disk in one operation. In our setup (which I assume is not a silly
setup), we had a query that took 4.5 seconds to execute on the primary
server and ~21 seconds to send the WAL records to our synchronous standby
server. After recompiling Postgres and setting MAX_WAL_SEND to 16MiB, that
21 seconds decreased to just 1.5 seconds, which is a 92.9% improvement.

Thank you for your comments in advance
Majid

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2024-01-10 22:27:57 Re: Emit fewer vacuum records by reaping removable tuples during pruning
Previous Message Heikki Linnakangas 2024-01-10 21:25:42 Re: Stack overflow issue