Stored-procedure trace
Pro Plus. Right-click any procedure in the schema browser → Trace… to open the Stored-procedure trace dialog. Three dialects supported, each using the engine’s native trace surface — no engine extension, no debugger attach.
Per-dialect trace approach
Section titled “Per-dialect trace approach”| Dialect | Trace surface |
|---|---|
| PostgreSQL | EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) CALL <proc>(args) |
| MySQL / MariaDB | SET profiling = 1; CALL …; SHOW PROFILE FOR QUERY 1; SET profiling = 0; |
| SQL Server | SET STATISTICS TIME ON; SET STATISTICS IO ON; EXEC <proc> args; SET STATISTICS … OFF; |
In all three cases the dialog never modifies the procedure body — the trace is purely a runtime hook. Safe to run on prod (the typed-name confirm still applies for prod-tagged connections).
What you see
Section titled “What you see”The dialog opens with three sections:
- Arguments — comma-separated, dialect-specific syntax (PG:
positional or named; MySQL: positional; MSSQL:
@param = value) - Stats mode — TIME / IO / both / none (MSSQL); for PG/MySQL the stats come back automatically from EXPLAIN ANALYZE / SHOW PROFILE
- Will execute preview — the exact SQL Quay’s about to run, so there’s no “what is the dialog doing under the hood” mystery
- Output panel — engine-native messages (PG NOTICE / MySQL warnings / MSSQL PRINT) plus the timing breakdown
What it tells you
Section titled “What it tells you”For each per-statement step inside the procedure:
- Duration — wall-clock + CPU (where the engine reports it)
- Rows / page reads / sort spills — engine-specific metrics
- Anchor — PG: the statement’s source-line; MSSQL: the optional PRINT marker before EXEC; MySQL: the SHOW PROFILES query id
No source-line attribution for MySQL — its profiling output is
per-CALL, not per-statement-in-the-proc-body. For per-statement
attribution in MySQL, instrument the procedure manually with
SELECT 'step:N' AS step; between statements.
Trade-offs vs a real debugger
Section titled “Trade-offs vs a real debugger”This isn’t pgAdmin / SQL Server Management Studio’s attach debugger. There are no breakpoints, no step-into, no variable inspection. What you get:
- Per-statement timing — enough to spot the slow line
- Per-statement IO — enough to spot the missing index inside the proc
- Engine-side error context — full stack traces from the engine, not Quay’s wrapper
For real interactive debugging, the engine vendors’ GUIs do that better; Quay’s trace is for “I have a 30-line procedure and one line is slow; tell me which”.
When AI is enabled
Section titled “When AI is enabled”The output panel gets an “AI summary” section that reads the trace + the procedure body and points out hot spots in plain language. Off by default; same opt-in toggle as elsewhere.
The deterministic timing breakdown above is unchanged. AI augments the output, doesn’t replace it.
Limits
Section titled “Limits”- Procedures that issue DDL — TRUNCATE / DROP / CREATE-as-side-effect. Those run for real (the trace doesn’t sandbox). Don’t trace destructive procedures on prod unless you want the side effect.
- Procedures that COMMIT internally — the trace is one transaction; an internal COMMIT splits the visibility. The output flags “internal commit at step N” so it’s not surprising.
- PG functions vs procedures — both work. For functions returning a value, the trace shows the function’s return at the end.