From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | ikedamsh(at)oss(dot)nttdata(dot)com |
Cc: | masao(dot)fujii(at)oss(dot)nttdata(dot)com, pgsql-hackers(at)postgresql(dot)org, tsunakawa(dot)takay(at)fujitsu(dot)com, magnus(at)hagander(dot)net |
Subject: | Re: New statistics for tuning WAL buffer size |
Date: | 2020-09-18 02:11:51 |
Message-ID: | 20200918.111151.904547272576133581.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Fri, 18 Sep 2020 09:40:11 +0900, Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Li Japin | 2020-09-18 03:00:14 | Re: Parallelize stream replication process |
Previous Message | Masahiro Ikeda | 2020-09-18 00:40:11 | Re: New statistics for tuning WAL buffer size |