Skip to main content

Statistics Tab: Reference

This page is the source of truth for the in-app Explain this panels on the Query Explorer detail view's Statistics 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).

The statistics model is richest on PostgreSQL; SQL Server and Oracle fill the shared rows with their nearest equivalents and show a dash where a counter has no counterpart. A dash means "this engine does not measure that," not "zero."

Execution Statistics​

The statement's execution profile for the selected window: how often it ran, how long it took on average and at the extremes, and how much block I/O time it spent.

Rows​

  • Calls in period — executions in the window.
  • Mean time — average execution duration. Rising reads red.
  • Execution time in period — total time spent executing across all calls; the statement's real cost.
  • Min time / Max time — the fastest and slowest observed executions, where the engine tracks them.
  • Rows — rows produced in the window.
  • Block I/O total time — time spent reading and writing data blocks, where the engine measures it.

A "Measured" timestamp on the card shows when the statistics were last collected. Each row's trend chip compares against the preceding window; the arrow's color follows whether rising is good (calls, rows) or bad (times).

Reading it​

The Min–Max spread is the diagnostic the averages hide: a tight spread means the statement is uniformly slow (plan or index work), a wide one means it is usually fast with bad outliers (contention, parameter sensitivity, or cache misses on cold values). And compare total Execution time in period across your top statements — the biggest total, not the worst mean, is where tuning pays back most.

Block Statistics​

Time this statement spent reading and writing data blocks — the I/O-wait component of its execution time.

Rows​

  • Block read time — time spent waiting for blocks to be read.
  • Block write time — time spent writing blocks out.

Availability​

These timings come from PostgreSQL's per-statement I/O instrumentation and require the database's track_io_timing setting to be enabled; without it — and on SQL Server and Oracle — the rows show a dash.

Reading it​

Compare block time against the statement's total execution time. A statement spending most of its time in block reads is storage-bound: the fix is cache (memory), fewer blocks (indexes, tighter predicates), or faster disks — not query logic. Near-zero block time on a slow statement means the time goes to CPU or locks instead, which the Activity Explorer's wait views can attribute.

Shared Blocks​

The statement's traffic against the shared buffer cache — the memory all sessions share for regular table and index data.

Rows​

  • Cache hits in period — block requests served from memory.
  • Hit % — hits as a share of all block accesses.
  • Read in period — blocks that had to come from disk.
  • Written in period / Dirtied in period — blocks this statement wrote or modified, where the engine reports them.

Availability​

PostgreSQL reports these natively per statement. For SQL Server and Oracle, Logstag maps the nearest equivalents — logical and physical read counters — onto the hit and read rows; the write and dirtied rows are PostgreSQL-specific and show a dash elsewhere.

Reading it​

Hit % is the headline: hot statements should live in the high nineties. A low hit rate with a large Read count is the statement paying disk price on every run — and if the Object Sizes treemap shows its table dwarfing memory, no amount of query tuning substitutes for an index that narrows the working set.

Local Blocks​

The statement's traffic against local buffers — PostgreSQL's per-session memory for temporary tables.

Rows​

Same shape as Shared Blocks — cache hits, hit percentage, reads, writes, and dirtied blocks — but counted against session-local buffers instead of the shared cache.

Availability​

Local buffers are a PostgreSQL concept; this card shows dashes for SQL Server and Oracle, and for PostgreSQL statements that never touch temporary tables.

Reading it​

Nonzero local-block traffic means the statement uses temporary tables. That is often fine by design — but a statement with heavy local reads is churning through temp data larger than its local buffer allowance, and a statement whose local traffic appeared out of nowhere usually gained a temp-table step in a recent code change worth a look in the Changes-aware views.