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.
What to look for
- Long-running statements.
- High total time.
- High execution count.
- High reads or writes where available.
- Queries related to waiting sessions.
Workflow
- Open Queries.
- Sort by the resource or duration that matches the symptom.
- Open query detail where available.
- Load PostgreSQL Execution Plans where available and drill into costly plan nodes.
- Compare with Activity, Waits, and Indexes.
- Use Performance Tune for guided review.
Live, history, and query intelligence
The Live tab reads the current pg_stat_statements view for the selected PostgreSQL server. It is useful when you want a quick view of the statements PostgreSQL is currently tracking.
The History tab reads Mini DBA Query Intelligence samples from the engine history shard for the selected engine, server, and time range. This is the better place to answer "what changed?", "has this query regressed?", and "did a plan change near an incident?". History data requires pg_stat_statements to be installed in the monitored database and readable by the monitoring login.
History filters include:
- Time range.
- Database.
- Query text search.
- Regressions only.
Open a query-history row to view the SQL text, metric trend, plan history, execution plan diagram, and nearby schema or configuration changes. Plan History stores selected PostgreSQL JSON plans, compares the newest and previous observations, and shows the visual diff where enough plan data is available. Nearby Changes shows schema, extension, and setting changes captured around the query sample time, including instance-level setting changes when a database filter is active.
Debug workload buttons
In debug builds, or in an administrator kiosk/debug session where enabled, the Queries page may show amber debug workload buttons:
- Trigger Query Workload creates a short
minidba_debug_queryload_*workload and forces Query Intelligence samples so query history can be tested. - Trigger Schema Change creates a controlled schema/config correlation event and then opens Query History filtered to the debug object.
- Trigger Plan Change creates a retained
minidba_debug_planchange_*table, captures a baseline plan, adds an index, captures the changed plan, and opens Query History filtered to the debug object.
These buttons are for Mini DBA validation and demos. They create temporary or retained debug objects in a writable non-system schema, preferably minidba_debug, and should not be used as a production tuning workflow.
How to prioritize PostgreSQL queries
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.
PostgreSQL query FAQ
Why is query history empty?
Query history is populated by the engine sampler, not by opening the page alone. Check that pg_stat_statements is loaded through shared_preload_libraries, created in the monitored database, and readable by the monitoring login. Also confirm that the selected time range, database filter, and query search are not excluding the sample.
Why is there no plan history for a query?
Mini DBA only captures plans for a bounded set of safe, high-value read-style statements. Plan capture can be skipped when a statement is unsafe to explain, cannot be parsed, is not selected by the sampler caps, or has not changed enough to recapture yet.
What does nearby changes show?
Nearby Changes lists low-cadence schema/config snapshots that changed around the query sample. Use it as supporting evidence for plan or runtime changes, not as proof that the change caused the regression.
Why do query totals change after restart?
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.
Why do similar SQL statements appear separately?
Queries may be grouped differently depending on available PostgreSQL statistics and extensions. Compare statement text, parameters, database, and application context.
Can Mini DBA show execution plans?
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.
Related pages
- PostgreSQL activity
- PostgreSQL execution plans
- PostgreSQL waits
- PostgreSQL indexes
- PostgreSQL extensions