Find your slowest queries with the Profiler

The Profiler answers the question that comes before tuning: which statement is the problem? Open it from the Profiler tab, pick a connection, and you get a ranked list of statements with how often each ran, how long it took, and how much of the database’s total time it accounts for.

Two sources, deliberately kept apart

The Profiler can read from two places, and they answer different questions. You choose which one you are looking at — they are never blended into one number, because a statement that looks rare in your own session may be the busiest thing on the server.

• Database — the engine’s own accounting. This covers every client that touches the database: your application, your colleagues, background jobs, cron. It is where real problems live, and it usually needs an extension or a permission to be switched on first.
• Session — what AddisDB itself has run on this connection. Nothing to set up and it works on every engine, but it only ever sees your own queries.

Turning on the database’s own accounting

Most engines can keep statement statistics but do not by default. If the Database source is unavailable, the Profiler tells you what is missing rather than showing an empty list.

• PostgreSQL — needs the pg_stat_statements extension. Ask whoever administers the server to add it to the shared preload libraries and create the extension; it is standard, ships with most distributions, and is safe to leave on.
• MySQL and MariaDB — read from the performance schema, which is usually on already.
• SQL Server — reads from the query store where it has been enabled for the database.
• Managed services — most cloud providers expose the same statistics, sometimes behind a parameter group setting you flip once.

Reading the list

Statements are grouped by shape, not by exact text. A query that ran a thousand times with a thousand different id values is one row, not a thousand — which is the only way the ranking means anything. The values themselves are replaced with placeholders in what you see.

Sort by total time rather than by the slowest single run. A query that takes 40ms and runs two million times a day costs far more than one that takes nine seconds once a night, and it is usually the cheaper one to fix.

From a slow statement to a fix

1. Pick the statement accounting for the largest share of total time.
2. Open it into the editor — the Profiler hands it straight across.
3. Ask the engine how it plans to run it, using the Plan panel beside your results.
4. Look for a scan where you expected an index lookup, or a row estimate wildly different from reality.

The companion article on reading a query plan covers what to look for once you get there.