RE: About to add WAL write/fsync statistics to pg_stat_wal view
От | Masahiro Ikeda |
---|---|
Тема | RE: About to add WAL write/fsync statistics to pg_stat_wal view |
Дата | |
Msg-id | 745b2bca8ea79d562d03f339ca193f9e@oss.nttdata.com обсуждение исходный текст |
Ответ на | RE: About to add WAL write/fsync statistics to pg_stat_wal view ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>) |
Список | pgsql-hackers |
On 2021-01-22 11:54, kuroda.hayato@fujitsu.com wrote: > Dear Ikeda-san, > > This patch cannot be applied to the HEAD, but anyway I put a comment. > > ``` > + /* > + * Measure i/o timing to fsync WAL data. > + * > + * The wal receiver skip to collect it to avoid performance > degradation of standy servers. > + * If sync_method doesn't have its fsync method, to skip too. > + */ > + if (!AmWalReceiverProcess() && track_wal_io_timing && > fsyncMethodCalled()) > + INSTR_TIME_SET_CURRENT(start); > ``` > > I think m_wal_sync_time should be collected even if the process is > WalRecevier. > Because all wal_fsync should be recorded, and > some performance issues have been aleady occurred if > track_wal_io_timing is turned on. > I think it's strange only to take care of the walrecevier case. Kuroda-san, Thanks for your comments. Although I thought that the performance impact may be bigger in standby servers because WALReceiver didn't use wal buffers, it's no need to be considered. I agreed that if track_wal_io_timing is turned on, the primary server's performance degradation occurs too. I will make rebased and modified. Regards, -- Masahiro Ikeda NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: