Date: Tue, 7 Jul 2026 11:02:03 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: pgsql-hackers@lists.postgresql.org
Subject: Add per-backend AIO statistics
Message-ID: <akzcq9jtWK5C92g1@bdtpg>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="Pi0/Nu3LVhi0Ij+H"
Content-Disposition: inline
Archived-At: <https://www.postgresql.org/message-id/akzcq9jtWK5C92g1%40bdtpg>
Precedence: bulk


--Pi0/Nu3LVhi0Ij+H
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi hackers,

Currently to monitor AIO we can use:

1/ pg_aios that lists all AIO handles that are currently in use. That shows
what's happening right now, but not what has happened.

2/ pg_stat_get_backend_io() that shows how much IO was done, but not how it
was done. There's no way to see whether IOs ran synchronously or
asynchronously, whether a backend was stalling on handle exhaustion, or how
completions are distributed across backends.

This patch helps answering those questions by exposing cumulative per-backend
AIO counters:

- started: total AIO operations initiated
- executed_sync: IOs executed synchronously (fallback path)
- executed_async: IOs submitted asynchronously
- completed_self: IO completions processed by the issuing backend
- completed_other: IO completions processed on behalf of another backend
- handle_waits: times waited for a free AIO handle
- submitted: number of submit calls to the IO method

These counters are useful for understanding and tuning AIO behavior:

- executed_async / started. A ratio near zero means the backend is falling back
to synchronous execution (TOAST chunk fetches, temp buffers, ...).

- a non-zero handle_waits means the backend exhausted all its AIO handles. That
could mean that io_max_concurrency is too low.

- completed_self vs completed_other reveals cross-backend completion patterns.
That helps see how IO completion work is distributed and could help interpret
per backend IO statistics values.

- executed_async / submitted gives the average batch size per submit call.

As far as the technical implementation:

This data can be retrieved with a new system function called
pg_stat_get_backend_aio(), that returns one row based on the PID provided in input.

pgstat_flush_backend() gains a new flag value, able to control the flush of the
AIO stats.

This patch relies mostly on the infrastructure provided by 9aea73fc61d4, that
has introduced backend statistics.

The overhead (4 functions calls and counters increments) kind of follow the same
patterns as pgstat_count_backend_io_op() and I did not observe measurable
regression (I did not expect to). Also that does not add that much memory
per-backend: PgStat_AioCounters is 56 bytes.

There is no "double" counting as a global view to show those counters does not
exist. I think that's better to start with the per-backend side of it and see
if we want to also add a global view. For example, completed_other identifies
which backends did IOs for other backends. Also this allows correlating with
pg_stat_activity and pg_stat_get_backend_io().

Examples based on Franck's blog post [1]:

1/ query the smalldocs table:

postgres=# select count(*),avg(length(data)) from smalldocs;
  count  |          avg
---------+-----------------------
 1024000 | 1024.0000000000000000
(1 row)

postgres=# SELECT * FROM pg_stat_get_backend_aio(pg_backend_pid());
 started | executed_sync | executed_async | completed_self | completed_other | handle_waits | submitted |          stats_reset
---------+---------------+----------------+----------------+-----------------+--------------+-----------+-------------------------------
    3125 |            46 |           3079 |             46 |               0 |            0 |      3078 | 2026-07-07 09:28:27.412136+00

We can see that the sequential scan fully benefits from AIO.

2/ query the largedocs table:

postgres=# select count(*),avg(length(data)) from largedocs;
 count |         avg
-------+----------------------
  1000 | 1048576.000000000000
(1 row)

postgres=# SELECT * FROM pg_stat_get_backend_aio(pg_backend_pid());
 started | executed_sync | executed_async | completed_self | completed_other | handle_waits | submitted |          stats_reset
---------+---------------+----------------+----------------+-----------------+--------------+-----------+-------------------------------
  121154 |        121150 |              4 |         121150 |               0 |            0 |         4 | 2026-07-07 09:35:00.504872+00

We can see that the sequential scan bypasses AIO.

Looking forward to your feedback.

[1]: https://dev.to/franckpachot/iouring-buffered-reads-in-postgresql-19-iouring-mcn

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

--Pi0/Nu3LVhi0Ij+H
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
	filename="v1-0001-Add-per-backend-AIO-statistics.patch"