PostgreSQL Queries shows expensive and notable query activity for a monitored PostgreSQL server. Use it to find statements affecting CPU, I/O, waits, and response time.
PostgreSQL query tuning is most effective when you focus on total impact instead of the most dramatic individual query. A statement that runs for several minutes once a day may matter, but a query that runs thousands of times per hour can consume more CPU and I/O overall. Sort by total time, mean duration, execution count, reads, and writes to find the workload that most affects users.
Use PostgreSQL Activity to confirm whether an expensive query is currently active. Then check PostgreSQL Waits to see whether it is delayed by locks, I/O, client waits, or another resource. If index evidence is available, open PostgreSQL Indexes before creating new indexes. Adding indexes without checking write overhead can make INSERT, UPDATE, and DELETE workloads slower.
For repeat investigations, capture the query fingerprint, database, application name, and approximate time window. This helps compare before and after behavior when a code release, parameter change, or index change is deployed.
Some PostgreSQL query statistics are reset when the server restarts or when statistics are explicitly reset. Treat the time window as part of the evidence.
Queries may be grouped differently depending on available PostgreSQL statistics and extensions. Compare statement text, parameters, database, and application context.
Where plan detail is available, use it alongside the query list. See PostgreSQL Execution Plans for the plan viewer, diagram, HTML export, and AI plan review workflow. If plan detail is not available, use duration, waits, indexes, and row activity to choose the next investigation step.