This page describes Calíope 1.7, the version I am building right now. 1.6 is on the App Store for the Mac, iPad, iPhone, Apple Watch, Apple TV and Apple Vision Pro. The changelog says which version each feature landed in.
Adds an “Open in Calíope” button to every topic. It only works with the app installed.
What the server recorded on its own about the queries that crossed its threshold, from every client.
Where it is: Workspace › Tools › Slow Queries
This is what the server wrote down on its own: the queries that crossed its threshold, from all of its clients and not only from Calíope. The app's own query log is a different thing —what you ran from here— and it lives in its own tool.
The bar offers up to three views, and which ones exist depends on the server: Settings, always; Entries, one row per execution, only if the engine keeps individual executions and lets a client read them; By statement, the summary grouped by query shape, only if the engine publishes it. A view the server cannot fill is not drawn dimmed: it is not drawn at all.
MySQLMariaDBAurora
The MySQL family gives both: mysql.slow_log keeps executions —with their time, their user and the literal text— and performance_schema keeps the summary by shape.
PostgreSQL
PostgreSQL keeps no executions a client can read: its log goes to a file on the server's machine. What it does publish is the aggregate, through pg_stat_statements, so here you will see By statement and not Entries.
SQL Server
SQL Server has no slow query log: no threshold and no recorded executions. What it does keep, always and without switching anything on, is the tally of every plan in its cache, and that is what you'll see under By statement. Entries doesn't appear.
To see a whole row —the full text and everything the server noted about it— double-click it on the Mac or tap it on the iPad. From its card you can copy the query or send it to the editor.
The picker on the right says how many rows are requested: fifty to see what is happening right now, a thousand to review the whole day. Auto-refresh reads again every ten seconds, and the bar says when what you are looking at was read.
Oracle
Oracle has no slow query log: no server threshold and no executions recorded one by one. What is read is the statement cache (V$SQL), which always keeps the figures of each statement while it stays there. Entries shows one row per statement at its average execution —time, CPU, reads and rows divided by the number of executions, shown next to them— and By statement, the summary grouped by shape. It is not a history: a statement that leaves the cache disappears with its figures, and a restart empties it. The internal queries of SYS and SYSTEM are left out, except your own if you sign in with one of those accounts. Reading V$SQL takes a dictionary privilege (SELECT_CATALOG_ROLE or SELECT ANY DICTIONARY); without it, the screen shows the server's error. AWR and the DBA_HIST_* views are not queried: they require a paid Oracle pack.
ClickHouse
ClickHouse gives both from system.query_log: the runs, read right after a SYSTEM FLUSH LOGS so what just ran is already there, and the summary by shape. The runs include the ones that failed, with their error in a column of its own, and carry the bytes read and the memory after the time; the time is the server's clock. Hide Calíope’s own, on by default, hides what Calíope queries on its own, never what you wrote in the editor.
Apple Vision Pro: as on iPad: look at the row and pinch to open it.
Turn the log on, move the threshold and choose where it writes — wherever the server lets you do it from here.
Where it is: Slow Queries › Settings
The cards at the top say what the server answers right now: whether it is recording, with which threshold, and where it writes. Below them appears one of two things: the controls to change it, or a note saying where it is really changed. Never dimmed controls, which cannot tell “not here” from “this is broken”.
The threshold is typed or moved with the minus and plus buttons, and sent with Apply. A negative one is refused right here: no query takes less than no time, and the server would clamp it to zero without a word — so every query would become slow and the log would grow unchecked.
MySQLMariaDBAurora
The threshold is in seconds (long_query_time), and the destination is chosen between the mysql.slow_log table, the server's file, or both (log_output). Only what goes to the table can be read from a client.
Two things that surprise people: a change made from here does not survive a restart of the server —for that it goes in its configuration file— and does not reach connections that are already open, Calíope's included: live sessions keep measuring with the previous value until they are recycled.
Aurora
On Amazon Aurora these settings do not live in the server but in the cluster's parameter group, so here you will see the note instead of the controls. Emptying the log is possible: the server itself does it with mysql.rds_rotate_slow_log.
PostgreSQL
The threshold is in milliseconds (log_min_duration_statement), and a change made from here does persist: it is written with ALTER SYSTEM and the server reloads its configuration.
But some sources win over it without saying so. If the value comes from the command line the server started with, or from a setting of this database, this role or this session, the write is accepted, the file ends up with the new value and the one in force is still the old one. That is why the first variable in the list below is the threshold source: it is what says where it has to be changed. When the source is one of those, here you will see the note and not the controls.
The destination is not a choice: PostgreSQL always writes to its own log, which is a file on the server's machine.
SQL Server
In SQL Server there is nothing to adjust: the plan cache always keeps count, and it has no threshold and no destination to choose. That's why the threshold card doesn't appear and you'll see the note instead of the controls. What is read lives in the server's memory: it is lost when the server restarts, and a plan that leaves the cache takes its numbers with it. With optimize for ad hoc workloads on, a one-off query only gets in on its second run.
The list at the end holds the variables this server publishes around the log, with the names it gives them. They are informational: they change wherever their own settings are changed, not here.
Oracle
In Oracle the threshold belongs to Calíope, not to the server: it is applied when reading, to each statement's average execution, and it is saved in this profile. Changing it touches nothing on the server and applies from the next read. It is in seconds, although the cache counts time in microseconds; if you haven't changed it, it is one second. There is no switch —the cache can't be turned off— and no destination to choose: what is read lives in the server's memory.
ClickHouse
The server keeps the threshold in milliseconds (log_queries_min_query_duration_ms), although here it's shown in seconds, and the destination is always system.query_log. The switch and the threshold are saved on your own account, with ALTER USER … MODIFY SETTINGS, and apply to that account's queries from the next one, not to everyone else's. If the account is defined in the server's configuration or lacks ALTER USER, you'll see the note instead of the controls. Emptying the log is TRUNCATE TABLE system.query_log, for the whole server.
Keywords: threshold, long_query_time, log_min_duration_statement, log_output, ALTER SYSTEM, parameter group
It groups by query shape, not by execution: it answers what is costing the server its day.
Where it is: Slow Queries › By statement
By statement does not list executions: it groups by the shape of the query. Literals are replaced by a placeholder, so a thousand queries that differ only in the value they look for are one row, with its calls, its total time and its mean time. It answers “what is costing this server its day?”, which is almost never the single slowest query.
MySQLMariaDBAurora
It is published by performance_schema, and literals come out as ?. On MariaDB it starts off: if this view says there is no summary, it is not that there are no slow queries — it is that performance_schema is OFF. It cannot be turned on with the server running: it goes in its configuration file and the server has to be restarted.
PostgreSQL
It is published by pg_stat_statements, and literals come out as $1. It needs two things, both outside the app: the library preloaded in shared_preload_libraries, which requires restarting the server, and the extension created in this database, once per database:
CREATE EXTENSION pg_stat_statements;
If the extension is created and the library is not loaded, the view exists and collects nothing. They are two different states, and the tool says which one you are in.
SQL Server
It comes from sys.dm_exec_query_stats, grouped by query_hash, which is the shape of the query. The text you see is that of one of its runs, with its literals, not a shape with placeholders. Reading it needs the VIEW SERVER STATE permission; without it, the view shows the server's error. Reset statistics doesn't appear: clearing this summary would be DBCC FREEPROCCACHE, which throws away the plans of the whole server, and that isn't done from here.
The summary belongs to the whole server, so privileges matter: where your user cannot read other people's queries, the server returns the row without the text. When that happens, it is said here with the number —how many more shapes there are that you cannot read— which is very different from an empty list.
Reset statistics zeroes those counters for the whole server, not for your session: it affects anyone looking at the same summary, and it cannot be undone.
Oracle
It comes from V$SQL, grouped by FORCE_MATCHING_SIGNATURE: two queries that differ only in a literal are one row, and the text you see is that of one of them. Statements without that signature —PL/SQL blocks, DDL— are grouped by their SQL_ID. The summary doesn't apply the threshold, and the maximum is the slowest average execution among those it groups: the cache doesn't keep each execution. Reset statistics doesn't appear, nor Empty the log in Entries: both would mean emptying the shared cache of the whole server.
ClickHouse
It comes from system.query_log, grouped by normalized_query_hash: two queries that differ only in a literal are one row, and the text you see is that of one of them. Reset statistics empties that same table, so it takes the runs with it, and the confirmation says so.
Keywords: summary, by statement, performance_schema, pg_stat_statements, normalized, privileges
The log says which query is slow; to know why, send it to the editor and profile it there.
Where it is: Slow Queries › right-click › Send to editor
The log says which query is slow. To know why, the query has to run again, and that is your decision — not that of a list refreshing every ten seconds.
From a row, through its context menu or by opening its card, Send to editor leaves the query in the SQL Editor, in a tab, without running it. There you decide what to do with it.
MySQLMariaDBAuroraClickHouse
Run it and press Profile to see the breakdown by phase, or ask the engine for its plan with visual EXPLAIN.
PostgreSQLSQL ServerOracle
Ask the engine for its plan with visual EXPLAIN. Profile, the breakdown by phase, belongs to the MySQL family and doesn't appear in the editor here.
Before running what a row brings, remember that the text is the one another client ran, with its parameters and against the database it had open.
MySQLMariaDBAuroraPostgreSQL
And from the per-statement summary what arrives is the normalized shape, with placeholders instead of values: you have to put your own values in before running it.
SQL ServerClickHouseOracle
From the per-statement summary what arrives is the text of one of its runs, with that run's values: the row stands for every run of the same shape.
Keywords: profile, profiler, editor, explain, plan, send to editor
What each button deletes on the server and with which engines it appears.
Where it is: Workspace › Tools › Slow Queries
Two buttons delete what the server has recorded, and neither can be undone.
- Empty the log, in Entries, deletes the recorded executions.
- Reset statistics, in By statement, sets the summary of the whole server back to zero, not just yours.
Both confirmations say how many rows will go, counted on the server before asking, and go through the environment tag’s protection. They appear only where the engine allows it and the session can write.
MySQLMariaDBAurora
With MySQL, MariaDB and Aurora both buttons are available.
PostgreSQL
With PostgreSQL only resetting the statistics is available.
ClickHouse
With ClickHouse both are available, and resetting the statistics also deletes the executions, because they are the same table.