Query Explorer
The Query Explorer shows query-level performance across your monitored databases: which statements run, how often, how long they take, and which ones carry alerts.
What the page shows
- One row per distinct statement shape. Repeated executions of the same statement — with different values — are grouped under one identity: PostgreSQL statements are parameter-normalized by the agent, SQL Server statements are grouped by the engine's own query hash, and Oracle statements by their SQL_ID.
- Query-level statistics are collected for PostgreSQL, SQL Server, and Oracle. Databases on other engines do not appear here.
- For Oracle, the agent samples the top statements by elapsed time each cycle; when an Oracle database tracks more unique statements than the list shows, a hint under the table says how many are tracked.
Selecting a row opens the query's detail view: summary metrics and trend charts, the full statement text, an execution plan where available, and detailed statistics.
Reading it
Sort by Execution Time for the slowest statements and by Calls for the busiest — the statement worth tuning first is usually high on both. The alert chips mark statements that already crossed thresholds; everything else here is proactive hunting.
Query List
One row per distinct statement observed in the selected window. Click a row to open the query's detail view.
Columns
- Query — the statement text, syntax-highlighted and clamped to a few lines; the detail view shows the full text.
- Database — the database the statement ran in, with its engine icon. Filterable.
- Instance — the hosting instance.
- Execution Time — the average execution duration, with a trend against the previous comparable period. Rising is shown red.
- Rows — rows the statement produced in the window, where the engine reports them.
- Calls — how many times the statement executed in the window.
- Alerts — active query-level alert counts as severity chips.
- Last Executed — when the statement last ran.
The list can be searched, filtered per column (execution-time and count ranges, engine, with/without alerts), sorted by most measures, and paginated with a selectable page size. Column visibility choices persist in your browser.
Reading it
Three sorts cover most tuning sessions: Execution Time for the slow, Calls for the busy, and Alerts for the already-flagged. A statement with modest per-call time but enormous call volume often costs more than the slowest query on the page — which is exactly what the Calls sort surfaces.
Query Detail
Selecting a query opens its detail view with three tabs:
| Tab | Purpose |
|---|---|
| Overview | The four summary metrics, the full statement text, trend charts, and the explain plan where available. |
| Statistics | The detailed execution profile: timing spread, block I/O, and buffer traffic. |
| Alerts | Query-level alerts matched to exactly this statement. |
Metric definitions and how each value is calculated live in the Overview reference and the Statistics reference.
Alert Signals
The list's alert chips and the detail view's Alerts tab show query-level alerts — engine checks such as high duration, high execution frequency, high CPU consumption, or excessive reads, matched to the statement's identity. Critical and high findings are the triage signal; medium and low add context.
Engine Data Requirements
Query Explorer depends on query-statistics visibility from the monitored engine:
| Engine | Requirement |
|---|---|
| PostgreSQL | The pg_stat_statements extension provides per-statement statistics; without it, query visibility is limited. |
| Microsoft SQL Server | Query Store gives the best historical visibility; without it, Logstag falls back to the engine's execution-statistics views, and only statements with a minimum execution count are tracked. |
| Oracle | SQL performance metadata must be visible to the monitoring user; the agent samples the top statements by elapsed time each cycle. |
If query data is missing, common causes include insufficient monitoring permissions, disabled query-statistics features, no query activity in the selected time window, collector delay, or an inactive database target.
Data Freshness
Query statistics are collected roughly every minute. Some engines expose cumulative counters, which Logstag converts into interval values for the selected window. Trend values compare the selected period with the previous comparable period; when the previous period has no usable data, the trend can be empty even though the current value is present.
Data Boundaries
Query Explorer displays operational query metadata: statement text, normalized query identifiers, database and instance names, execution counts, row counts, timing, cache and block statistics, alert context, and explain plans where available. Logstag does not execute queries from this surface and does not copy application table rows through it.
Statement text deserves specific care: on PostgreSQL, the agent parameter-normalizes text before it leaves the database host, so literal values are replaced with placeholders and not retained. On SQL Server and Oracle, text is stored as the engine exposes it and can include literal values from application queries. Access to Query Explorer should be limited to users who are allowed to read SQL text, not just performance metrics.