Restrict data checksums entries in pg_stat_io
Hi,
While reviewing the data checksums docs at [1]/messages/by-id/CAHGQGwFsBjQs2fv7b72hxzGV_fJMh6LAg4E83pNfDOu1jVgWCA@mail.gmail.com, I found that the data checksums
launcher and workers are exposed in pg_stat_io with the same broad set of
object/context combinations as general background workers.
However, several of those entries can never accumulate I/O statistics.
For example, as far as I understand correctly, the launcher never processes
relations itself, and the workers neither operate on temporary relations nor
use the bulkread or bulkwrite contexts. So I think it would be better to
restrict the reported entries to those that the data checksums processes
can actually use.
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:
- data checksums launcher: relation/normal, wal/init, wal/normal
- data checksums worker: relation/normal, relation/vacuum, wal/init, wal/normal
The patch also excludes WAL reads for both processes, since they emit
WAL records but never read WAL.
Thoughts?
Regards,
[1]: /messages/by-id/CAHGQGwFsBjQs2fv7b72hxzGV_fJMh6LAg4E83pNfDOu1jVgWCA@mail.gmail.com
--
Fujii Masao
Attachments:
v1-0001-Restrict-pg_stat_io-entries-for-data-checksum-pro.patchapplication/octet-stream; name=v1-0001-Restrict-pg_stat_io-entries-for-data-checksum-pro.patchDownload+32-11
On 10 Jul 2026, at 05:13, Fujii Masao <masao.fujii@gmail.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!
--
Daniel Gustafsson
On Mon, Jul 13, 2026 at 6:47 PM Daniel Gustafsson <daniel@yesql.se> wrote:
On 10 Jul 2026, at 05:13, Fujii Masao <masao.fujii@gmail.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
Attachments:
v2-0001-Restrict-pg_stat_io-entries-for-data-checksum-pro.patchapplication/octet-stream; name=v2-0001-Restrict-pg_stat_io-entries-for-data-checksum-pro.patchDownload+34-9
On 16 Jul 2026, at 19:13, Fujii Masao <masao.fujii@gmail.com> wrote:
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.
Interesting, I didn't realize that any catalog read could use bulkread but it
clearly makes sense.
So I've updated the patch to keep relation/bulkread for both data checksums
processes. Patch attached.
+1
--
Daniel Gustafsson
On Fri, Jul 17, 2026 at 5:12 PM Daniel Gustafsson <daniel@yesql.se> wrote:
On 16 Jul 2026, at 19:13, Fujii Masao <masao.fujii@gmail.com> wrote:
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.Interesting, I didn't realize that any catalog read could use bulkread but it
clearly makes sense.So I've updated the patch to keep relation/bulkread for both data checksums
processes. Patch attached.+1
Thanks for the review! I've pushed the patch.
Regards,
--
Fujii Masao