Skip to main content
Metoro charts show what their queries are actually doing while they run and what they cost once they finish. This makes it easy to understand why a chart is slow, how much data a query scans, and to stop queries you no longer need.

​
Live query progress

While a metric query runs, the chart’s loading indicator shows live progress streamed from the database: how much data has been scanned so far and, when an estimate is available, how far along the query is (for example, “1.2 GB scanned · 34%”). Progress appears on time series charts, tables, pie charts, and bar gauges. Fast queries may complete before any progress is worth showing; in that case you just see the result.

​
Cancelling a query

If a query has been running for more than a second, a Cancel control appears under the progress indicator. Cancelling aborts the query in the browser and also stops the query inside the database, so it stops consuming resources immediately. A cancelled chart shows a Run again control to re-run the query. Queries are also cancelled automatically when you navigate away or scroll a chart out of view, so off-screen charts never keep expensive queries running.

​
Query statistics

After a query completes, charts show a small summary in their header, for example “1.2 GB · 3.4 s”. Hovering over it shows the full detail: rows and bytes scanned, wall-clock duration, and how many database queries were issued to serve the chart. The same statistics are returned on the API responses as an optional queryStats field:
A few notes on interpreting the numbers:
  • bytesRead (and the “scanned” figure in charts) is the uncompressed, in-memory size of the data the query processed, matching ClickHouse’s own progress reporting. The actual disk and network I/O is typically 10-20x smaller thanks to compression.
  • cachedRowsRead and cachedBytesRead report the scan cost that was originally paid to compute any parts of the response served from Metoro’s query response cache. They are separate from rowsRead/bytesRead, which only count work the database performed for this request; the chart badge shows the combined figure with the cached share broken out on hover. The fields are omitted when nothing was served from the cache, and results cached before this feature existed report 0.
  • subQueries counts every database query issued for the request; a single chart typically issues at least two (a metric type lookup plus the main query), and more when results are split across multiple metrics.
  • clickhouseElapsedMs is the server-side time summed across all sub-queries, so it can exceed durationMs when sub-queries run concurrently.
  • requestId can be used to find every sub-query of a request in ClickHouse’s system.query_log (it is set as the log_comment and used as the query_id prefix).
  • progressAvailable is false when the deployment connects to ClickHouse over HTTP, which cannot stream progress; queries still work, but scan counters are not reported.