This page describes Calíope 1.5, the version we are building right now. 1.4 is finished and in App Review, and the store serves 1.3 on the Mac and 1.2 on iPad. 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.
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.
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.
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.
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.
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.
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: run it and press Profile to see the breakdown by phase, or ask the engine for its plan with visual EXPLAIN.
Two cautions before running what a row brings. The text is the one another client ran, with its parameters and against the database it had open. 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.
Keywords: profile, profiler, editor, explain, plan, send to editor