Analyze where I/O comes from with pg_stat_io (backend type, object, context)
PostgreSQLExtensionsCommand
SELECT backend_type,
object,
context,
reads,
pg_size_pretty(reads * op_bytes) AS read_size,
writes,
pg_size_pretty(writes * op_bytes) AS write_size,
extends,
hits,
round(100.0 * hits / NULLIF(hits + reads, 0), 1) AS hit_pct,
evictions,
reuses,
fsyncs,
round(read_time::numeric, 1) AS read_ms,
round(write_time::numeric, 1) AS write_ms
FROM pg_stat_io
WHERE coalesce(reads, 0) + coalesce(writes, 0) + coalesce(extends, 0) + coalesce(evictions, 0) > 0
ORDER BY coalesce(reads, 0) + coalesce(writes, 0) DESC;
-- Who writes? Ideally most writes come from the checkpointer and background writer
SELECT backend_type,
pg_size_pretty(sum(writes * op_bytes)) AS written,
round(100.0 * sum(writes) / NULLIF(sum(sum(writes)) OVER (), 0), 1) AS pct_of_writes,
sum(fsyncs) AS fsyncs
FROM pg_stat_io
WHERE object = 'relation' AND writes > 0
GROUP BY backend_type
ORDER BY sum(writes) DESC;What it does
Shows reads, writes, extends, evictions and fsyncs by backend type (client backend, autovacuum, checkpointer...), object (relation/temp relation) and context (normal, vacuum, bulkread, bulkwrite); and which process types the writes come from.
When to use it
During an I/O bottleneck, to tell whether the load comes from queries, autovacuum or checkpoints, and to validate shared_buffers/bgwriter settings.
Caution
pg_stat_io is cluster-wide and cumulative since the last reset; take the difference between two samples to see change (to reset: SELECT pg_stat_reset_shared('io');). read_time/write_time are populated only with track_io_timing = on. reads also includes reads served from the OS page cache. High client backend writes or evictions mean backends write buffers themselves to free space; review shared_buffers, bgwriter_lru_maxpages and checkpoint settings. Rows with context = 'vacuum'/'bulkread' reflect ring buffer usage; reuses there are normal.