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.
Workflow
- Open the PostgreSQL server in the navigation tree.
- Select Activity.
- Sort by duration, wait, database, user, or query where available.
- Investigate blockers and long-running sessions first.
- Open PostgreSQL Execution Plans where plan detail is available.
- Continue to Queries, Waits, or Deadlocks.
Live and historical activity
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.
Activity tabs and lock chains
Activity separates current sessions into focused tabs such as active sessions, blocking sessions, blocked sessions, lock chains, and idle sessions. Start with active and blocked sessions for "what is slow now?", then use Lock Chains when one blocked session may be part of a wider blocking tree.
The Lock Chains tab shows each waiter/blocker relationship with role, depth, wait event, blocker PID, blocked PIDs, duration, database, user, and query text. The Diagram view draws the same chain so the root blocker, intermediate blockers, and waiting sessions are easier to follow. Hover tooltips use the central Mini DBA tooltip style and explain what each process or edge means in a PostgreSQL lock context.
In debug builds, or in an administrator kiosk/debug session where enabled, the Activity page may show an amber Trigger Lock Chain button. It creates a bounded minidba_debug_lockchain_* blocking chain so the lock-chain grid and diagram can be validated. The workload is rolled back and cleaned up automatically after the inspection window.
How to interpret PostgreSQL activity
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 a PostgreSQL JSON plan, use the Execution Plan tab to inspect the PEV diagram, raw plan, and AI plan review. Drill into expensive plan nodes before recommending indexes or query rewrites. Older stored observations or unavailable plans may show a raw-plan fallback instead of the diagram.
PostgreSQL activity FAQ
Why does PostgreSQL show idle sessions?
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.
Why are idle in transaction sessions important?
Idle in transaction sessions can hold locks and prevent vacuum cleanup. Investigate them quickly if other sessions are waiting.
How do I find the root blocker?
Open Lock Chains and look for blocker/root rows with no upstream blocker. The diagram places waiting sessions and blockers into a visual chain so the session causing the largest queue is easier to identify.
Should I tune the query or the server first?
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.
Related pages
- PostgreSQL queries
- PostgreSQL execution plans
- PostgreSQL waits
- PostgreSQL deadlocks
- PostgreSQL indexes