Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Andrew <adhenry.9@gmail.com>
Mime-Version: 1.0 (1.0)
Subject: Re: wal segment size
Date: Fri, 19 Dec 2025 09:26:17 +0100
Message-Id: <2890CAF1-6B00-440E-B8FF-3D333DFC5AF3@gmail.com>
References: <4e2cfc51d3933a1df28e212ccb0b90f39633422a.camel@cybertec.at>
Cc: Greg Sabino Mullane <htamfids@gmail.com>,
 Colin 't Hart <colinthart@gmail.com>,
 PostgreSQL General <pgsql-general@lists.postgresql.org>
In-Reply-To: <4e2cfc51d3933a1df28e212ccb0b90f39633422a.camel@cybertec.at>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Archived-At: <https://www.postgresql.org/message-id/2890CAF1-6B00-440E-B8FF-3D333DFC5AF3%40gmail.com>
Precedence: bulk

As an oracle dba new to Postgres, I=E2=80=99m used to the concept of context=
 switches and latch issues with regards to transaction log switches. Does Po=
stgres have a similar mechanism with latching etc when it switches to a new w=
al segment that is alleviated when increasing the size of the wal segments?

Regards
Andrew
Sent from my iPhone

> On 17 Dec 2025, at 18:58, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>=20
> =EF=BB=BFOn Wed, 2025-12-17 at 12:21 -0500, Greg Sabino Mullane wrote:
>>> On Wed, Dec 17, 2025 at 11:10=E2=80=AFAM Colin 't Hart <colinthart@gmail=
.com> wrote:
>>> Thanks Laurenz, that confirms what I was assuming. Archiving is via pgba=
ckrest
>>> to a backup server, over SSH. Approx 750ms to archive each segment is cr=
azy --
>>> I'll check compression parameters too.
>>=20
>> Switch to archive-async =3D on. When doing that, the typical time drops t=
o 10ms or less.
>> Also use a compress-type of lz4 or zst, which perform way better than the=
 default gz.
>> If you are encrypting, that's a bottleneck you just have to deal with, no=
 shortcuts there. :)
>=20
> I second that.  Asynchronous archiving in pgBackRest tends to work around t=
he problem.
>=20
>> tl;dr try other things before messing with the WAL size. The current size=
 can work very
>> well even on very large and very, very busy systems.
>=20
> On the other hand, 16MB on a very busy system is somewhat ridiculous.
> A somewhat bigger segment size may be appropriate.
>=20
> Yours,
> Laurenz Albe
>=20
>=20