Re: New statistics for tuning WAL buffer size

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: New statistics for tuning WAL buffer size
Дата
Msg-id 20200918.111151.904547272576133581.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: New statistics for tuning WAL buffer size  (Masahiro Ikeda <ikedamsh@oss.nttdata.com>)
Ответы Re: New statistics for tuning WAL buffer size
Список pgsql-hackers
At Fri, 18 Sep 2020 09:40:11 +0900, Masahiro Ikeda <ikedamsh@oss.nttdata.com> wrote in 
> Thanks. I confirmed that it causes HOT pruning or killing of
> dead index tuple if DecodeCommit() is called.
> 
> As you said, DecodeCommit() may access the system table.
...
> The wals are generated only when logical replication is performed.
> So, I added pgstat_send_wal() in XLogSendLogical().
> 
> But, I concerned that it causes poor performance
> since pgstat_send_wal() is called per wal record,

I think that's too frequent.  If we want to send any stats to the
collector, it is usually done at commit time using
pgstat_report_stat(), and the function avoids sending stats too
frequently. For logrep-worker, apply_handle_commit() is calling it. It
seems to be the place if we want to send the wal stats.  Or it may be
better to call pgstat_send_wal() via pgstat_report_stat(), like
pg_stat_slru().

Currently logrep-laucher, logrep-worker and autovac-launcher (and some
other processes?) don't seem (AFAICS) sending scan stats at all but
according to the discussion here, we should let such processes send
stats.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



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

Предыдущее
От: Masahiro Ikeda
Дата:
Сообщение: Re: New statistics for tuning WAL buffer size
Следующее
От: Li Japin
Дата:
Сообщение: Re: Parallelize stream replication process