RE: About to add WAL write/fsync statistics to pg_stat_wal view

From: Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>
To: kuroda(dot)hayato(at)fujitsu(dot)com
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: About to add WAL write/fsync statistics to pg_stat_wal view
Date: 2021-01-22 12:14:28
Message-ID: 745b2bca8ea79d562d03f339ca193f9e@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-01-22 11:54, kuroda(dot)hayato(at)fujitsu(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2021-01-22 12:21:45 Re: Online checksums patch - once again
Previous Message Magnus Hagander 2021-01-22 11:56:10 mkid reference