Re: should we enable log_checkpoints out of the box?

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: should we enable log_checkpoints out of the box?
Дата
Msg-id CAH2-WzkqT647AY7Y=sC52j3DbdGo9QmHsch-DCMFaB0KSb-ZhQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: should we enable log_checkpoints out of the box?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: should we enable log_checkpoints out of the box?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Nov 2, 2021 at 11:50 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I almost proposed 1m rather than 10m, but then I thought the better of
> it. I think it's unlikely that an autovacuum that takes 1 minute is
> really the cause of some big problem you're having on your system.
> Typical problem cases I see are hours or days long, so even 10 minutes
> is pretty short. compared to what's likely to cause you real issues.
> And at the same time 10 minutes is also high enough that you won't get
> frequent log messages.

I think that 10 minutes is fine. But if it has to be 30 minutes, then
that's also probably fine.

I think that the case for enabling autovacuum logging is particularly
good. The really big problems with autovacuum often involve
anti-wraparound VACUUM, where you really want to have every possible
opportunity to learn why VACUUM took much longer than expected.

Going from doing index vacuuming in one single pass to requiring more
than one pass can very significantly delay things, quite suddenly.
Even when you have 95% of the maintenance_work_mem required to process
indexes in a single pass, it might not be that much better than 50% or
less. It's way too unpredictable in cases where users actually run
into real problems -- cases where it actually matters.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nikolay Samokhvalov
Дата:
Сообщение: Re: should we enable log_checkpoints out of the box?
Следующее
От: Melanie Plageman
Дата:
Сообщение: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)