active_time

The active_time metric measures the cumulative time, in milliseconds, that PostgreSQL database sessions have spent actively executing SQL statements. This metric reflects actual query execution time where the database is performing work on behalf of client connections, excluding time spent idle, waiting for locks, or in other non-execution states. Introduced in PostgreSQL 14 as part of the pg_stat_database system view, this metric provides crucial visibility into how much computational effort the database is expending and serves as a key indicator of workload intensity and resource utilization patterns.

From an operational perspective, active_time is essential for understanding database performance characteristics, capacity planning, and identifying periods of high query activity that may correlate with application behavior or business cycles. When analyzed alongside metrics like idle_in_transaction_time and transaction counts, it helps operators distinguish between databases that are genuinely busy executing queries versus those that are idle or blocked. Tracking active_time per database enables teams to identify which databases consume the most execution resources, making it valuable for cost allocation in multi-tenant environments and for prioritizing optimization efforts. The metric accumulates monotonically as a counter, so analyzing the rate of change over time windows reveals trends in query execution intensity and helps establish baseline patterns for normal operations.

Healthy patterns for active_time depend heavily on application workload characteristics, but sudden spikes or sustained increases often warrant investigation as they may indicate inefficient queries, missing indexes, or unexpected application behavior. Common alerting scenarios include setting thresholds on the rate of change of active_time to detect abnormal query execution patterns or using it in ratio with sessions_active to identify when average query duration increases significantly. During troubleshooting, correlating elevated active_time with pg_stat_statements data helps pinpoint specific expensive queries driving high execution time, while comparing it against CPU utilization metrics reveals whether execution time aligns with available compute resources or if contention exists.