| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Colin 't Hart <colinthart(at)gmail(dot)com> |
| Cc: | PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: wal segment size |
| Date: | 2025-12-17 17:58:45 |
| Message-ID: | 4e2cfc51d3933a1df28e212ccb0b90f39633422a.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-12-17 18:37:34 | Re: Record last SELECT on a row? |
| Previous Message | Igor Korot | 2025-12-17 17:42:41 | Re: [GENERAL] Retrieving query results |