pg_stat_activity is a PostgreSQL system view for observing server processes and their current activity. Use it when performance symptoms need to be tied to work actually happening inside the database: excessive concurrent activity, long-running statements, or clues that point back to application code, schema design, configuration, or ingestion. section 11.3.3 section 6.3
A common mistake is to treat the number of client connections as the database’s real workload. When many sessions access the same objects, Lightweight Locks (LWLocks) can become contended and reduce throughput; many rows showing wait_event_type LWLock in pg_stat_activity indicate possible excessive concurrency. The safer response is usually to limit clients, let requests queue for available connections, or place a pooler such as PgBouncer in front of PostgreSQL rather than continually raising connection capacity. section 6.3 section 6.3
Checking a long-running active statement
For actively executing queries, inspect now() - query_start in pg_stat_activity to find statement duration. Do not equate this with every slow completion: a query may be delayed because it is blocked rather than actively executing. Long execution holds a transaction snapshot, which can prevent autovacuum from cleaning dead tuples and contribute to bloat and XID wraparound. If necessary, pg_cancel_backend(<PID>) can stop a long-running query; that is generally safe for the database, though the client application may be affected. section 6.5.2 section 6.5.2 section 6.5.2
Use the view as part of a methodical investigation, not as an isolated tuning ritual. Combine activity monitoring with logs, pg_stat_statements, schema inspection, exploratory queries, and configuration review; then turn confirmed findings into small, measurable repair projects. section 11.3.3
