Re: should we enable log_checkpoints out of the box?

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: should we enable log_checkpoints out of the box?
Дата
Msg-id CABUevExR0G4TXhJoEu2dEcF-GiOVpw+qpbN9ax2Cv43aEdyEHg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: should we enable log_checkpoints out of the box?  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: should we enable log_checkpoints out of the box?  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
On Sun, Oct 31, 2021 at 9:05 PM Tomas Vondra <tomas.vondra@enterprisedb.com> wrote:
On 10/31/21 21:16, Andres Freund wrote:
> Hi,
>
> On 2021-10-31 15:43:57 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> On 2021-10-31 10:59:19 -0400, Tom Lane wrote:
>>>> No DBA would be likely to consider it as anything but log spam.
>>
>>> I don't agree at all. No postgres instance should be run without
>>> log_checkpoints enabled. Performance is poor if checkpoints are
>>> triggered by anything but time, and that can only be diagnosed if
>>> log_checkpoints is on.
>>
>> This is complete nonsense.
>
> Shrug. It's based on many years of doing or being around people doing
> postgres support escalation shifts. And it's not like log_checkpoints
> incurs meaningful overhead or causes that much log volume.
>

Yeah. In tuned instances the checkpoints happen fairly infrequently most
of the time (occasional batch loads being an exception, etc.), so the
extra log traffic should be fairly negligible. And it's not like we can
make checkpointer infinitely smart - sometimes the cause is a change in
the workload etc.

OTOH most of this data (# of timed/xlog checkpoints, buffers written by
checkpointer etc.) is available in the pg_stat_bgwriter view, and people
generally have monitoring these days.

Yeah, I think you can get much of the data you need in pg_stat_bgwriter. There is still some data that log_checkpoint gives you that the statistics don't -- but maybe we should instead look at exposing that information in pg_stat_bgwriter, rather than changing the default.


--

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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: parallel vacuum comments
Следующее
От: "osumi.takamichi@fujitsu.com"
Дата:
Сообщение: RE: Failed transaction statistics to measure the logical replication progress