Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vEkKI-00HB4X-3K for pgsql-admin@arkaria.postgresql.org; Fri, 31 Oct 2025 08:17:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1vEkKH-00Ct5l-0Y for pgsql-admin@arkaria.postgresql.org; Fri, 31 Oct 2025 08:17:36 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vEkKG-00Ct5d-JF for pgsql-admin@lists.postgresql.org; Fri, 31 Oct 2025 08:17:35 +0000 Received: from mail-oa1-x33.google.com ([2001:4860:4864:20::33]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vEkKD-004hbx-31 for pgsql-admin@lists.postgresql.org; Fri, 31 Oct 2025 08:17:34 +0000 Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-3d2059871d0so1382285fac.3 for ; Fri, 31 Oct 2025 01:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dbtune.com; s=google; t=1761898653; x=1762503453; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=VTVSV3W9jMJfhWrtubyawJw0ZDWGNNWF2u3GnHAsNCY=; b=VeNjTvXem0pGzVTdhYBGVVX9pzveRn3tzN1F8doapEISQTkESCbThIHOqhZ5TvBete gPGvK2XeKkNF4e/diejJZRcxLEm9K3OEF1bOqVpS+O0+9LjOKD1utOL0ugIcXbQ4f4Rh WgQ5OxJtR6WFUN+FmFhgnT+wDbmqiD0OQ1Gg8YpEvoy9OZux7/rKa7OPZ+HrZ8/NoG6o A/kg9sfpcWJoBg7Cq9vLNFE1yCn7S3L7Vv5+9BOSotYorVaW4fIWnXV7/M7y7aUNsfpO H7EoaqcYYgdR+Nlq223uV3CGVrgJPTQqTnknm4DRM5aH76XtuVINln2WWFUpQbklePr0 vDJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761898653; x=1762503453; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=VTVSV3W9jMJfhWrtubyawJw0ZDWGNNWF2u3GnHAsNCY=; b=RXDo3fa9N9G+lB+pE3BxsLd5OMZTAEyugZ/yvuSLWuaEjopsP/0/pyPVeBHijhG3aG 8pu4uec6CDHaZpgIT1d/ZZJHVP1mErHDPnOitgMX9I4qcAKWCKdo9r6ZOfpx5h4jYzhw cmALgPb0ptPpV2WeJeSo6CmQPSnrzRkU2Mj+sraVcFMnpHqT4xgN/6qhJXH5aWowKLtV YlBwezhH0SJzlM7KJIF0cNHPLvReAegaPigmUyfcK9Ki4LyZiCoyR5WqUw+991DHQENl RFMWQ6XqSWOKEzbvep6TBhD67RHieUHRAwsZFJMXeTaa6IdnnzwaFkpZqCGrm468QxQY PoqA== X-Gm-Message-State: AOJu0YzmTx4c61AV8gmeiRW/7AMZTRPw/wl78TVQt1gIPQYvo4EgGu0c 3xCKpZ/W0Fm/Ng97dsD1bwHsjrxagf6ja36ti/fL/Sv6U/kah0CxVN8AWup+CClb0z70xEKdFtD RgmW5a9WCjL1O7A0HXfSJxQVpWJLtWagOZT2ZSr28hhUFFuK2VSts1vU= X-Gm-Gg: ASbGncv9tQXXkKbGwaf3lTAmjfh29pFeY/oMLeeMBUxQUbXzw2JG9xoYh6RUaCAJtym sk4xm611SgCqvLsAtyK9EnHvQwyHap1b2Cpm/hfGQK31ttLwZ7EvwZa2JmHtW1ElXu7E4KwZj9a sbSL8VdrY6Hd/zFqlo/T+iCdJF+xcsc6gu4XZSD56DVe85XmAvVN/FL37ijt80pANXOe0PIFlGe EG+VZn08NxYzzt7j6L6oRRHvSp45AiJmEdfJojHUmpFaqgm+yxEKPwFXMIgkQ== X-Google-Smtp-Source: AGHT+IGVoJTcwzGDkabQTeznGfj1rgm/Y3vRx6dgC9VyeHIUXnWFBxXMqT7OaAF1rT9Hqmyor6XUixY3XK5Uvr/RfYY= X-Received: by 2002:a05:6870:b411:b0:3d3:abb1:6c5 with SMTP id 586e51a60fabf-3daccf0362amr1620630fac.48.1761898653164; Fri, 31 Oct 2025 01:17:33 -0700 (PDT) MIME-Version: 1.0 From: Shardul Borhade Date: Fri, 31 Oct 2025 09:17:22 +0100 X-Gm-Features: AWmQ_blArJfQor9YoLhljmmwXT_NGx0WiVEp_vGjkLgsI5RtdG0zybA6qlhX7Gw Message-ID: Subject: Question on pg_stat_io showing zero reads/writes for I/O workers To: pgsql-admin@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000005a33f406426fff4e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005a33f406426fff4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi team, I=E2=80=99m running into an issue with pg_stat_io. When I run the following= query: SELECT backend_type, reads, writes, read_time FROM pg_stat_io WHERE backend_type LIKE '%io%'; I consistently get: backend_type | reads | writes | read_time --------------+-------+--------+----------- io worker | 0 | 0 | 0 io worker | 0 | 0 | 0 io worker | 0 | 0 | 0 io worker | 0 | 0 | 0 io worker | 0 | 0 | 0 io worker | 0 | 0 | 0 io worker | | 0 | io worker | 0 | 0 | 0 (8 rows) I tried running a heavy sequential scan on a 55 GB table as well as a bitmap heap scan, but the reads and writes columns still show zero. However, I can clearly observe performance differences when I tune the io_workers configuration, so I believe they are active. Am I missing something here? Could someone please help me understand why the stats aren=E2=80=99t being reflected in pg_stat_io? Do I need to enable= any other server parameter to log this information? Thanks and regards, Shardul B --0000000000005a33f406426fff4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi team,

I=E2=80=99m running into an issue with pg_stat_io. When I r= un the following query:

SELECT backend_type, reads, writes,=
 read_time
FROM pg_stat_io
WHERE backend_type LIKE '%io%';

I consistently get:

 backend_type | reads | writes | read_time=20
--------------+-------+--------+-----------
 io worker    |     0 |      0 |         0
 io worker    |     0 |      0 |         0
 io worker    |     0 |      0 |         0
 io worker    |     0 |      0 |         0
 io worker    |     0 |      0 |         0
 io worker    |     0 |      0 |         0
 io worker    |       |      0 |         =20
 io worker    |     0 |      0 |         0
(8 rows)

I tried running a heavy sequential scan on a 55 GB table as well as a bi= tmap heap scan, but the reads and writes columns = still show zero.

However, I can clearly observe performance differences when I tune the <= code>io_workers configuration, so I believe they are active.

Am I missing something here? Could someone please help me understand why= the stats aren=E2=80=99t being reflected in pg_stat_io? Do I = need to enable any other server parameter to log this information?

Thanks and regards,

Shardul B

--0000000000005a33f406426fff4e--