How to
Check How Heavy a Query Is
See how long a single SQL query took, how big its result is and, where the database reports it, how much memory and CPU it used, with a plain-language verdict on whether it is a good query.
Updated November 14, 2026
After you run a query in Single DB mode, a Query cost bar appears under the results. It shows a verdict, Good, Needs attention or Heavy, with the run time and result size. Click it to see the reasons and the numbers behind them.
Nothing extra runs on a normal Run. The bar uses what the run already measured plus anything the database sends back with the result.
Reading the verdict
Each reason says what was found and what to try. Examples:
- Slow: the database took several seconds to answer. Filter earlier or aggregate in the query.
- Large result: many megabytes were returned. Select fewer columns or add a
LIMIT. - Reads far more rows than it returns: the database scanned many rows to return a few. Filter on an indexed, sorted or partition column. This is not flagged for queries that aggregate (
GROUP BY,DISTINCT, window functions,COUNTand similar), because reading many rows is what they do. - Spilled to disk: a sort or hash did not fit in memory. Reduce the rows being sorted or grouped.
Confidence tells you how much the verdict is based on:
| Confidence | Based on |
|---|---|
| Low | This run only: time and result size |
| Medium | The database's own plan estimate, plus this run |
| High | Numbers reported by the database (rows read, memory, CPU) |
The editor shows at most the first rows of a result. The bar says so when the preview was cut short; judge the cost of the full query accordingly.
Analyze in database
Click Analyze in database for the database's own numbers. This asks the database for its plan and runs the query once more to measure it, so use it on queries you are happy to run twice. It is skipped when the database expects to read about 200 million rows or more.
What each database reports
| Database | Plan estimate | Rows and data read | Memory | CPU time |
|---|---|---|---|---|
| ClickHouse | Yes | Yes | Yes (shown on every run) | Yes (after Analyze) |
| PostgreSQL | Yes | Yes | Sort/hash memory when it fits; spill size when it does not | Not reported: PostgreSQL has no per-query CPU counter |
| MySQL, SQL Server, Oracle, BigQuery, Redshift | Not yet | Not yet | Not yet | Not yet |
For databases marked "Not yet", the bar still shows the run time, rows and result size, with low confidence.
Good to know
- Analyze follows the same rules as a normal run: you can only analyze what you can run, row-level security applies, and the analysis is recorded in the audit log.
- If the database cannot answer (for example you lack a privilege), that part says it is unavailable and the rest still shows.
- The bar is for single SQL queries.