PostgreSQL Activity shows current server activity for a monitored PostgreSQL instance. Use it to identify busy sessions, long-running queries, waiting sessions, and blocking behavior.
The PostgreSQL Activity page includes the Mini DBA Time Range selector. Use Live to watch current sessions, blockers, waits, and long-running statements, or switch to Last Hour, Last 12 Hours, Last Day, Last Week, or Custom to review captured session history. Mini DBA loads and caches the selected historical activity dataset for the current console session and server context, so reviewing the loaded historical sessions and moving between related views stays quick. Use Back to Live to resume live updates, then choose another historical range when you need a different incident window.
PostgreSQL Activity is the first page to use when users report that a PostgreSQL application is slow right now. It shows live database sessions, which makes it useful for separating a current production incident from a historical trend. Long-running active queries, idle transactions, sessions waiting on locks, and sessions tied to a single application user can all point to different causes.
Start with the sessions that have been active or waiting the longest. A long-running SELECT may need query tuning, an idle transaction may be holding locks, and many sessions with the same wait event may indicate an I/O, lock, or client-side bottleneck. If a session is blocked, use the blocking information and then move to PostgreSQL Waits or PostgreSQL Deadlocks for supporting evidence.
Activity is also helpful after a deployment or configuration change. Compare the application name, database, user, and statement pattern with the time of the change. If a new release creates more sessions, longer transactions, or repeated statements, the problem may be in connection handling or application behavior rather than PostgreSQL configuration.
When a selected session includes plan text or XML, use the Execution Plan tab to inspect the plan diagram, raw plan, and AI plan review. Drill into expensive plan nodes before recommending indexes or query rewrites.
Idle sessions are connected but not currently running work. They are normal in connection-pooled applications, but many idle sessions can still consume connection slots.
Idle in transaction sessions can hold locks and prevent vacuum cleanup. Investigate them quickly if other sessions are waiting.
Use the live activity pattern to decide. One expensive statement points toward query tuning, while many sessions waiting on the same resource may require server, storage, or application concurrency work.