PostgreSQL pg_stat_io: Reading I/O by Backend Type

The disks on your PostgreSQL server are busy and latency is climbing. pg_stat_statements tells you which queries read the most blocks, but not who does the writes: the checkpointer, the background writer, autovacuum, or the client backends that should be serving queries. pg_stat_io, added in PostgreSQL 16, answers that by splitting cluster-wide I/O by backend type, object, and context. PostgreSQL 18 changed the view: op_bytes is gone, read_bytes, write_bytes, and extend_bytes replace it, and WAL gets its own rows. This guide explains the rows and columns, the questions they answer, and how to sample them so the numbers mean something.

Scope and review date: November 2026. This post covers pg_stat_io in PostgreSQL 16, 17, and 18, with a note on PostgreSQL 19, which was at release candidate stage with general availability planned for 19 November 2026. Columns, defaults, and functions were checked against the PostgreSQL documentation and release notes on 9 November 2026. The queries were not run in a lab, and all output shown is illustrative.

What does pg_stat_io show, and which versions have it?

The PostgreSQL 16 documentation describes pg_stat_io as one row for each combination of backend type, target I/O object, and I/O context, with cluster-wide totals. Combinations that make no sense are left out: the checkpointer never writes temporary tables, so there is no checkpointer row for temp relation. Operations a row can never perform show as NULL: the background writer does not read, so its reads is NULL.

The three key columns take these values:

Two kinds of I/O do not appear: relation I/O that bypasses shared buffers, such as moving a table to another tablespace, and temp files written by sorts and hashes.

-- Every row that has done any relation or WAL I/O since the last reset
SELECT backend_type, object, context,
       reads, writes, extends, hits, evictions, reuses, fsyncs
FROM pg_stat_io
WHERE reads > 0 OR writes > 0 OR extends > 0 OR hits > 0
ORDER BY backend_type, object, context;

Interpretation: NULL means "this backend type never does this here", and 0 means "it could, but has not". Each process flushes its counters at most once per second, when it goes idle, so a query still running is not yet in the totals.

What do the pg_stat_io columns mean?

Each operation has a count and, in most cases, a matching time in milliseconds. The descriptions below follow the PostgreSQL 18 pg_stat_io reference.

The time columns depend on track_io_timing, which is off by default because it reads the clock around every I/O. Measure that overhead with pg_test_timing before you turn it on.

SHOW track_io_timing;
SHOW track_wal_io_timing;          -- PostgreSQL 18: controls the wal rows

-- Turn it on cluster-wide without a restart
ALTER SYSTEM SET track_io_timing = on;
SELECT pg_reload_conf();

Interpretation: once it is on, read_time / reads is the average wait per read. A rising average with flat reads points at storage latency, not more work.

What changed in pg_stat_io in PostgreSQL 17 and 18?

PostgreSQL 17 kept the pg_stat_io columns unchanged. The 17 release notes remove buffers_backend and buffers_backend_fsync from pg_stat_bgwriter as redundant with pg_stat_io, and move the checkpoint columns into a new pg_stat_checkpointer view. The 18 release notes change the view itself.

In PostgreSQL 18, reads counts operations and read_bytes their total size, without assuming one block per operation. On 16 and 17, multiply the counts by op_bytes instead.

-- PostgreSQL 18: byte columns, plus average size per read
SELECT backend_type, context,
       pg_size_pretty(read_bytes)  AS read_volume,
       pg_size_pretty(write_bytes) AS write_volume,
       pg_size_pretty(read_bytes / NULLIF(reads, 0)) AS avg_read
FROM pg_stat_io WHERE object = 'relation'
ORDER BY read_bytes DESC NULLS LAST;

Interpretation: large bulkread or vacuum read volumes show how much disk traffic is scans and maintenance rather than point lookups.

WAL rows in PostgreSQL 18

With object = 'wal', writes count WAL writes and fsyncs count WAL flushes, attributed to the process that issued them. Context init covers the writes that create new WAL segments.

SELECT backend_type, context, writes,
       pg_size_pretty(write_bytes) AS written,
       fsyncs, round(fsync_time::numeric, 1) AS fsync_ms
FROM pg_stat_io
WHERE object = 'wal'
ORDER BY write_bytes DESC NULLS LAST;

Interpretation: committing client backends often flush WAL themselves, so client backend rows here are normal. A high fsync_ms / fsyncs average means the WAL device is slow at durable writes, and with synchronous_commit on, every commit waits for it.

Per-backend I/O in PostgreSQL 18

pg_stat_get_backend_io(pid) returns the same fields as pg_stat_io for one backend process. It skips the checkpointer, background writer, startup process, and autovacuum launcher, which already have their own rows.

SELECT a.pid, a.application_name, b.context, b.reads, b.writes, b.extends
FROM pg_stat_activity AS a,
     LATERAL pg_stat_get_backend_io(a.pid) AS b
WHERE a.backend_type = 'client backend'
  AND b.object = 'relation' AND b.reads > 0
ORDER BY b.reads DESC
LIMIT 10;

Interpretation: this names the connections behind a read spike. Behind a connection pooler, one server process serves many clients, so the result is blurred.

Where is a page read or write counted?

I/O is charged to the process that issued it, not to the query that caused it. The same dirty page can be a checkpointer write one day and a client backend write the next.

A page already in shared buffers counts as a hit. Otherwise the backend takes a buffer from another page (an eviction), writes it first if it is dirty, and reads the new page. The kernel may serve that read from its page cache, so a read in pg_stat_io is not always a disk read. writebacks are the follow-up requests asking the kernel to start writing pages to disk.

Are client backends or the checkpointer doing the writes?

The documentation says client backends should normally rely on the checkpointer and background writer to write dirty data, and that large numbers of writes or fsyncs by client backends could indicate a misconfiguration of shared buffers or of the checkpointer.

Then look at the background writer and checkpointer views to see why.

-- PostgreSQL 17 and later
SELECT buffers_clean, maxwritten_clean, buffers_alloc
FROM pg_stat_bgwriter;

SELECT num_timed, num_requested, buffers_written
FROM pg_stat_checkpointer;

Interpretation: a climbing maxwritten_clean means the background writer keeps hitting bgwriter_lru_maxpages (100 by default, per bgwriter_delay round of 200 ms). num_requested well above num_timed means WAL volume forces checkpoints early, which usually points at max_wal_size. In PostgreSQL 18 both include skipped checkpoints; num_done counts completed ones.

The documentation also notes that a high evictions count can mean shared_buffers should be larger. A falling client backend hit ratio, hits / (hits + reads) in context normal, plus many client backend writes makes that case stronger; many client backend fsyncs point at the checkpointer instead. Some client backend writes are normal, so watch the trend. Our checkpoint and WAL tuning guide covers the settings.

What do the bulkread, bulkwrite, and vacuum rows mean?

Large one-pass operations cycle through a small ring of buffers so a big scan cannot flush hot data out of shared buffers. The buffer manager README gives the sizes:

• bulkread: sequential scans of large tables use a 256 kB ring.
• bulkwrite: COPY into a table and CREATE TABLE AS use 16 MB, but not more than one eighth of shared_buffers.
• vacuum: the ring size is vacuum_buffer_usage_limit. The default is 256 kB in PostgreSQL 16 and 2 MB in PostgreSQL 18, capped at one eighth of shared_buffers.

In these contexts, evictions counts buffers taken from shared buffers to join a ring, and reuses counts a ring buffer used again.

SELECT backend_type, context, reads, writes, evictions, reuses,
       round(read_time::numeric) AS read_ms
FROM pg_stat_io
WHERE context IN ('bulkread', 'bulkwrite', 'vacuum')
  AND (reads > 0 OR writes > 0)
ORDER BY reads DESC NULLS LAST;

Interpretation: a large client backend row in bulkread means big sequential scans, often a missing index or a report running on the primary. A bulkwrite row with high read or write time shows bulk loads competing with normal traffic.

How much I/O is vacuum doing?

Buffers that vacuum dirties stay in its ring: WAL is flushed and the buffer is written so it can be reused. Those writes appear as autovacuum worker writes in context vacuum. A manual VACUUM from a session counts under client backend, still in context vacuum.

-- Manual vacuum with a larger ring for one big table (PostgreSQL 16+)
VACUUM (VERBOSE, BUFFER_USAGE_LIMIT '64MB') orders;

Interpretation: a larger ring can make one vacuum finish sooner but evicts more useful pages. If autovacuum worker rows dominate read volume at peak, revisit cost limits and per-table thresholds with our autovacuum tuning guide before resizing the ring.

Does pg_stat_io show temp files and work_mem spills?

No. The temp relation object means temporary tables, which live in each session's local buffers (sized by temp_buffers). Sorts, hashes, and other operations that exceed work_mem spill to temp files, and pg_stat_io does not track those. Use pg_stat_database, which counts every temp file whatever its cause, and pg_stat_statements to find the query.

-- work_mem spills, per database
SELECT datname, temp_files, pg_size_pretty(temp_bytes) AS temp_written
FROM pg_stat_database
WHERE temp_files > 0
ORDER BY temp_bytes DESC;

-- The statements behind them
SELECT queryid, calls, temp_blks_written, left(query, 60) AS query
FROM pg_stat_statements
ORDER BY temp_blks_written DESC
LIMIT 10;

Interpretation: raise work_mem for the statements at the top, per role or per session, not cluster-wide; our shared_buffers and work_mem guide explains why. log_temp_files = 0 logs every temp file with its size.

The temp relation rows have a different meaning: many evictions and writes there mean temporary tables are outgrowing temp_buffers. Raise it in the sessions that build them, before their first temporary table.

How do you spot relation extension pressure?

When a table or index needs more space, a backend extends the file. Many sessions inserting into one table can queue on the relation extension lock.

SELECT backend_type, context, extends,
       round(extend_time::numeric, 1) AS extend_ms,
       round((extend_time / NULLIF(extends, 0))::numeric, 3) AS ms_per_extend
FROM pg_stat_io
WHERE extends > 0
ORDER BY extends DESC;

-- What sessions are waiting on right now
SELECT wait_event_type, wait_event, count(*)
FROM pg_stat_activity
WHERE wait_event IS NOT NULL
GROUP BY 1, 2 ORDER BY 3 DESC;

Interpretation: a rising ms_per_extend for client backends, together with sessions waiting on Lock / extend ("waiting to extend a relation") or IO / DataFileExtend, is extension pressure. Batching inserts, partitioning, or faster storage are the usual responses. Our post on PostgreSQL wait events covers the wait side.

How do you reset pg_stat_io and sample deltas?

Lifetime totals mix last month's bulk load with this morning's incident. You need the change over a known window.

Reset. SELECT pg_stat_reset_shared('io'); zeroes the view for everyone, including monitoring agents that compute rates from it. It is restricted to superusers by default, though EXECUTE can be granted. Per the PostgreSQL 18 documentation, calling pg_stat_reset_shared() with NULL or no argument resets all the shared views at once. pg_stat_reset_backend_stats(pid) resets one backend's counters.

Snapshot and diff. This changes nothing shared, so it is the safer default.

-- 1. Take a baseline
CREATE TABLE io_snap AS
SELECT now() AS taken_at, * FROM pg_stat_io;

-- 2. After the busy window, in a new transaction
SELECT c.backend_type, c.object, c.context,
       c.reads     - s.reads     AS reads,
       c.writes    - s.writes    AS writes,
       c.extends   - s.extends   AS extends,
       c.hits      - s.hits      AS hits,
       c.evictions - s.evictions AS evictions,
       round((c.read_time  - s.read_time)::numeric, 1)  AS read_ms,
       round((c.write_time - s.write_time)::numeric, 1) AS write_ms,
       now() - s.taken_at AS sampled_over
FROM pg_stat_io AS c
JOIN io_snap AS s USING (backend_type, object, context)
WHERE coalesce(c.reads - s.reads, 0) + coalesce(c.writes - s.writes, 0)
    + coalesce(c.extends - s.extends, 0) > 0
ORDER BY writes DESC NULLS LAST;

Interpretation: every number is now per window, so you can compare windows. A negative delta means someone reset the view in between; check stats_reset and start again.

How do you diagnose an I/O-heavy workload step by step?

The checks above, in order, for a server whose storage is the bottleneck.

For step 7, see our pg_stat_statements guide.

Frequently asked questions

Key takeaways

Review your PostgreSQL I/O with JusDB

JusDB's PostgreSQL performance tuning team can review your pg_stat_io, pg_stat_statements, and checkpoint statistics under a read-only role, and help plan changes to shared_buffers, work_mem, and autovacuum settings with before-and-after measurements.

Bring your PostgreSQL version, current settings, and snapshots from a busy period. Your team approves every production change.

Related reading

• pg_stat_statements: query performance analysis in PostgreSQL
• PostgreSQL performance tuning: shared_buffers, work_mem, and memory configuration
• PostgreSQL checkpoint and WAL tuning for high throughput
• PostgreSQL documentation: the pg_stat_io view