In most cases, a wait event occurs when the system waits for a specific type of resources to execute an SQL statement. Monitoring wait events helps you identify performance bottlenecks and determine whether the root cause is CPU saturation, I/O throughput, or lock contention.
Query wait events
Use the polar_stat_activity view to see which wait events are occurring most frequently across active client connections:
SELECT
CASE WHEN wait_event_type IS NULL THEN 'CPU' ELSE wait_event_type END,
CASE WHEN wait_event IS NULL THEN 'CPU' ELSE wait_event END,
COUNT(*) AS wait_count
FROM
polar_stat_activity
WHERE
state='active' AND backend_type='client backend'
GROUP BY wait_event_type, wait_event ORDER BY wait_count DESC; \watch 1Whenwait_event_typeandwait_eventare NULL, the process is using CPU rather than waiting for an external resource. The query maps NULL to'CPU'so that CPU-bound activity appears alongside other wait event types.
Interpret the results
The query returns wait events grouped by type. Use the following thresholds to identify bottlenecks:
| Wait event type | Bottleneck indicator |
|---|---|
| CPU | CPU wait events account for 80% or more of CPU cores, sustained over time. |
| I/O | A high count of I/O wait events sustained over time. |
| LWLock | A high count of lwlock wait events sustained over time. Lightweight locks (lwlocks) protect the data structure in your database. |
| Lock | A high count of lock wait events sustained over time. These are table locks or row locks in your database. |
When a single wait event type consistently dominates the results, investigate the corresponding resource as the likely cause of the performance issue.