Re: wal segment size - Mailing list pgsql-general

From Andrew
Subject Re: wal segment size
Date
Msg-id 2890CAF1-6B00-440E-B8FF-3D333DFC5AF3@gmail.com
Whole thread Raw
In response to Re: wal segment size  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: wal segment size
List pgsql-general
As an oracle dba new to Postgres, I’m used to the concept of context switches and latch issues with regards to
transactionlog switches. Does Postgres have a similar mechanism with latching etc when it switches to a new wal segment
thatis 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:
>
> On Wed, 2025-12-17 at 12:21 -0500, Greg Sabino Mullane wrote:
>>> On Wed, Dec 17, 2025 at 11:10 AM Colin 't Hart <colinthart@gmail.com> wrote:
>>> Thanks Laurenz, that confirms what I was assuming. Archiving is via pgbackrest
>>> to a backup server, over SSH. Approx 750ms to archive each segment is crazy --
>>> I'll check compression parameters too.
>>
>> Switch to archive-async = on. When doing that, the typical time drops to 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. :)
>
> I second that.  Asynchronous archiving in pgBackRest tends to work around the problem.
>
>> 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.
>
> On the other hand, 16MB on a very busy system is somewhat ridiculous.
> A somewhat bigger segment size may be appropriate.
>
> Yours,
> Laurenz Albe
>
>



pgsql-general by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Dealing with SeqScans when Time-based Partitions Cut Over
Next
From: Andrus
Date:
Subject: How to get single table data from backup