| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Restrict data checksums entries in pg_stat_io |
| Date: | 2026-07-16 17:13:24 |
| Message-ID: | CAHGQGwEJ4vySkqCPezRBN-xvG29=WYAj=9xEdFAq6JWcQGdYbA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 13, 2026 at 6:47 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> > On 10 Jul 2026, at 05:13, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> (Sorry for the delayed review)
>
> > The attached patch teaches pgstat_tracks_io_object() and pgstat_tracks_io_op()
> > about the actual I/O paths used by these processes. After the patch,
> > pg_stat_io includes only:
>
> Patch LGTM, and your reasoning around the IO usage of the launcher/worker is
> correct. Thanks!
Thanks for the review!
While reviewing the patch again, I've started thinking that relation/bulkread
should not be removed for the data checksums processes.
Both the launcher and the worker use table_beginscan_catalog(), which
can select BAS_BULKREAD when scanning large catalogs, i.e., pg_database
for the launcher and pg_class for the worker. As a result, seems their
I/O can be reported under the bulkread context.
So I've updated the patch to keep relation/bulkread for both data checksums
processes. Patch attached.
Regards,
--
Fujii Masao
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Restrict-pg_stat_io-entries-for-data-checksum-pro.patch | application/octet-stream | 4.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-07-16 17:21:27 | TDE: Benchmarking WAL encryption approaches |
| Previous Message | surya poondla | 2026-07-16 16:56:59 | Re: Fix races conditions in DropRole() and GrantRole() |