From: | "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com> |
---|---|
To: | 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | "vignesh21(at)gmail(dot)com" <vignesh21(at)gmail(dot)com>, "amit(dot)kapila16(at)gmail(dot)com" <amit(dot)kapila16(at)gmail(dot)com>, "sawada(dot)mshk(at)gmail(dot)com" <sawada(dot)mshk(at)gmail(dot)com>, "gregn4422(at)gmail(dot)com" <gregn4422(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: Failed transaction statistics to measure the logical replication progress |
Date: | 2021-12-20 09:40:19 |
Message-ID: | TYCPR01MB83736371B66F90C71365ED11ED7B9@TYCPR01MB8373.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Friday, December 17, 2021 2:03 PM Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> It sends stats packets at every commit-like operation on apply workers. The
> current pgstat is so smart that it refrain from sending stats packets at too high
> frequency. We already suffer frequent stats packets so apply workers need to
> bahave the same way.
>
> That is, the new stats numbers are once accumulated locally then the
> accumulated numbers are sent to stats collector by pgstat_report_stat.
Hi, Horiguchi-san.
I felt your point is absolutely right !
Updated the patch to address your concern.
Best Regards,
Takamichi Osumi
Attachment | Content-Type | Size |
---|---|---|
v18-0002-Extend-pg_stat_subscription_workers-to-include-g.patch | application/octet-stream | 27.3 KB |
v18-0001-Fix-alignments-of-TAP-tests-for-pg_stat_subscrip.patch | application/octet-stream | 7.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2021-12-20 09:43:20 | Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace |
Previous Message | Zhihong Yu | 2021-12-20 09:21:10 | Re: simplifying foreign key/RI checks |