Re: wal segment size
| От | Andrew |
|---|---|
| Тема | Re: wal segment size |
| Дата | |
| Msg-id | 2890CAF1-6B00-440E-B8FF-3D333DFC5AF3@gmail.com обсуждение исходный текст |
| Ответ на | Re: wal segment size (Laurenz Albe <laurenz.albe@cybertec.at>) |
| Ответы |
Re: wal segment size
|
| Список | 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 по дате отправления: