Performance Monitoring on Postgres Scripts

Monitor PostgreSQL Wait Events Using pg_stat_activity

Sun, 17 May 2026 00:00:00 +0000

Understanding PostgreSQL Wait Events for Performance Analysis

Every active PostgreSQL backend is either executing work or waiting. When a session waits, PostgreSQL records the reason in pg_stat_activity using two columns: wait_event_type and wait_event. Aggregating these across all sessions gives a clear picture of where your database is spending idle time — and what is holding it back.

Common wait event types include Lock (heavyweight locks between transactions), LWLock (internal lightweight locks), IO (disk reads and writes), IPC (inter-process communication), and Client (waiting on application input). A cluster dominated by IO waits may need larger shared_buffers; a cluster dominated by Lock waits has contention between transactions that needs investigation at the query level.

Monitor PostgreSQL Vacuum Progress with pg_stat_progress_vacuum

Sat, 16 May 2026 00:00:00 +0000

Tracking Active Vacuum and Autovacuum Workers in PostgreSQL

PostgreSQL vacuum is the maintenance process that removes dead tuples left behind by updates and deletes, reclaims storage, and prevents transaction ID wraparound. On active databases, autovacuum runs continuously in the background, but knowing whether it is actually making progress — and on which tables — requires querying the pg_stat_progress_vacuum view.

Introduced in PostgreSQL 9.6, pg_stat_progress_vacuum exposes one row per active vacuum worker, including both manual VACUUM commands and autovacuum background workers. The view shows the current phase, block counts scanned and vacuumed, and dead tuple statistics. This is the primary tool for answering the operational question: is vacuum keeping up, and if not, where is it stuck?