Overview Tab: Metric Reference
This page is the source of truth for the in-app Explain this panels on the
Query Explorer detail view's Overview tab.
Each section is written once as a content partial under _explain/ and rendered both here
and inside the dashboard's info panel (scripts/build-explain.mjs compiles the registry).
Calls in Period
How many times this statement executed during the selected window.
How it's calculated
- The agent collects the engine's query statistics roughly every minute and Logstag counts the executions that fall inside the window; the trend compares against the preceding window.
Source by engine
| Engine | Source |
|---|---|
| PostgreSQL | pg_stat_statements call counters |
| SQL Server | Query Store runtime statistics, falling back to sys.dm_exec_query_stats when Query Store is off |
| Oracle | v$sqlarea execution counters |
Reading it
Calls are the multiplier on everything else: a 5 ms statement at a million calls costs more than a 2-second statement running hourly. When calls jump without a traffic change, suspect a new code path or a loop — the classic N+1 signature the Insights page also watches for.
Mean Execution Time
The statement's average execution duration over the selected window. Rising is treated as a regression and shown red.
How it's calculated
- Computed from the engine's execution-time and call counters collected across the window; the trend compares against the preceding window.
- The unit adapts — sub-second averages keep millisecond precision.
Source by engine
| Engine | Source |
|---|---|
| PostgreSQL | pg_stat_statements execution-time counters |
| SQL Server | Query Store runtime statistics or sys.dm_exec_query_stats elapsed-time counters |
| Oracle | v$sqlarea elapsed-time counters |
Reading it
Means hide tails — the Statistics tab's Min/Max spread tells you whether this is a consistently-slow statement or a usually-fast one with terrible outliers, which are fixed differently (the first by plan or index work, the second usually by contention or parameter-sensitivity hunting).
Rows in Period
How many rows this statement produced during the selected window, where the engine reports row counts.
How it's calculated
- Summed from the engine's per-statement row counters across the window:
pg_stat_statementsrows on PostgreSQL, row counts from the query statistics on SQL Server,rows_processedon Oracle. - The trend compares against the preceding window; a dash means the engine did not report row counts for this statement.
Reading it
Rows per call is the ratio to watch: divide by Calls in Period. A statement returning thousands of rows per call to an application that displays twenty is shipping data nobody reads — pagination or a tighter predicate fixes more than index tuning would.
Cache Hit
How much of this statement's data access was served from memory rather than disk, as a percentage.
How it's calculated
The formula is engine-specific, using each engine's own counters:
| Engine | Source |
|---|---|
| PostgreSQL | buffer-block counters from pg_stat_statements — blocks hit in cache as a share of all blocks accessed (shared and local) |
| SQL Server | logical versus physical reads — the share of logical reads that did not require a physical read |
| Oracle | logical versus physical reads (buffer_gets and disk_reads), same shape as SQL Server |
Reading it
High is good, and for hot statements it should be very high — a busy statement in the low nineties or below is doing real disk work on every execution. A cache-hit drop with an unchanged query usually means the working set outgrew memory or something else evicted it; correlate with the database's own memory pressure on the Database Explorer.
Query
The statement's full text, syntax-highlighted and formatted for the engine's SQL dialect.
What you're looking at
- PostgreSQL — the text is parameter-normalized by the Logstag agent before it leaves the database host: literal values are replaced with
$1,$2, … placeholders, and the original text with its literals is not retained. What you see is the statement's shape, shared by every execution regardless of values. - SQL Server — the text as the engine's query statistics expose it. Depending on how the application sends statements, it can include literal values.
- Oracle — the statement text as Oracle exposes it, capped at a 4,000-character preview; very long statements are marked as truncated. It too can include literal values.
Reading it
This is the exact shape the metrics on this page describe — one row of statistics per statement shape, not per execution. When the text surprises you (an unexpected join, a missing predicate), you are usually looking at the reason for the numbers above it. Access note for administrators: because SQL Server and Oracle text can carry literal application values, Query Explorer access should track who is allowed to read SQL, not just metrics.
Performance Trends
The statement's behavior over time: four charts tracking calls, mean execution time, rows, and cache hit rate across the selected window.
How to read them
- Each chart mirrors one of the summary tiles above it, bucketed over the window; the bucket size adapts to the window length.
- All four share a synchronized hover — moving the cursor on one moves it on all, so you can line up a latency spike with the call volume and cache behavior at the same instant.
- Gaps in a line are honest: no samples were collected for that stretch, not zero.
Reading it
The diagnosis usually falls out of which charts move together. Mean time up with calls flat and cache hit down: the working set changed — think data growth or eviction. Mean time up with calls up: contention under load. Mean time up alone, everything else flat: a plan change — on PostgreSQL, check the Explain Plan below; on SQL Server, this is what Query Store's plan history exists for.
Explain Plan
The execution plan Logstag captured for this statement — the engine's own description of how it runs the query.
Availability
- PostgreSQL — shown when a plan has been collected for the statement.
- SQL Server and Oracle — not currently available on this surface; use the engine's native plan tools (Query Store,
v$sql_plan) for plan analysis there.
Reading it
The plan is presented as the engine produced it. The classic things to scan for: sequential scans on large tables where an index was expected, row-estimate versus reality mismatches, and join strategies that changed since the statement was last fast. Read alongside the trend charts — a mean-time step change with a plan that no longer matches expectations is a plan regression, and the fix is index or statistics work rather than query rewriting.