PostgreSQL 18 Adds New Stats Columns to Track Timing, I/O, and Parallel Activity

PostgreSQL 18 introduces several new statistics columns that give database administrators a more granular view of what's happening under the hood. The additions touch three key areas: timing measurements, byte-level I/O reporting, and parallel query execution.

New Time Tracking Columns in pg_stat_all_tables

Database operators often need to know how long specific maintenance operations take. PostgreSQL 18 adds four columns to the pg_stat_all_tables view specifically for this purpose:

  • total_vacuum_time
  • total_autovacuum_time
  • total_analyze_time
  • total_autoanalyze_time

These columns track the cumulative time spent on vacuum and analyze operations, broken down by whether they were manually triggered or run automatically. This makes it easier to spot tables where maintenance operations are taking an unusually long time.

Improved I/O Reporting with Byte-Level Statistics

Identifying I/O bottlenecks often requires understanding not just the number of operations but the volume of data being moved. PostgreSQL 18 expands pg_stat_io with three columns that report I/O activity in bytes:

  • read_bytes
  • write_bytes
  • extend_bytes

These replace the existing op_bytes column, which provided a single aggregate view of all read, write, and extend operations. The split into three separate columns offers a clearer, more detailed picture of where data is flowing.

Additionally, VACUUM and ANALYZE operations run with the VERBOSE option now report WAL, CPU, and average read statistics, giving you more context when diagnosing performance issues during maintenance operations.

Parallel Query Statistics

Parallel query execution has been a standard part of PostgreSQL for several versions, but tracking how often parallelism is actually used—or attempted—has been limited. PostgreSQL 18 adds two columns to pg_stat_statements to fill that gap:

  • parallel_workers_to_launch: the number of parallel workers that the planner intended to launch
  • parallel_workers_launched: the number of parallel workers that were actually launched

The difference between these two numbers can reveal cases where the planner wanted to use parallelism but was unable to, which is useful for tuning max_parallel_workers and related settings.