Query Plan Visualizer
Run EXPLAIN ANALYZE from the QueryDeck editor and read the visual plan tree for PostgreSQL and MySQL.
For: PostgreSQL and MySQL queries that are correct but slower than expected.
QueryDeck can run EXPLAIN ANALYZE from the SQL editor and render the result as a visual plan tree. Instead of reading raw planner output, you can inspect each execution node with its cost, actual row count, and time spent.
Open the visualizer
In the SQL editor:
- Put the cursor inside the query you want to inspect, or select the query.
- Right-click and choose
Explain Query. - QueryDeck runs
EXPLAIN ANALYZEand opens the plan below the editor.
The keyboard shortcut is Cmd+Option+E.
What the tree shows
Each node represents one operation in the database's execution plan. QueryDeck surfaces the values you need to answer three questions:
- What operation ran? For example a sequential scan, index scan, join, or sort.
- How much work did the planner expect? Planner cost and estimated rows show the expected shape.
- What happened in reality? Actual rows and execution time show what the database really did.
The tree view makes expensive branches easier to spot than the raw text representation, especially when a plan contains nested joins or multiple scans.
What to look for first
When a query is unexpectedly slow, start with:
- Nodes consuming a large share of the total execution time.
- Sequential scans on large tables where an index might be appropriate.
- Large gaps between estimated rows and actual rows.
- Expensive joins, sorts, or repeated loops high in the tree.
The plan tells you where the database spent its time. It does not automatically mean every sequential scan is bad or every index is good; use the actual row counts and timings as the evidence.
EXPLAIN ANALYZE executes the query
ANALYZE measures real execution, so the database runs the underlying statement. Treat it like running the query normally, especially on production connections.
QueryDeck's connection colors and Touch ID gate still help you distinguish sensitive connections, but the safest default is to analyze read queries when you are diagnosing production performance.
AI optimization uses the real plan when available
QueryDeck's Optimize action can include EXPLAIN ANALYZE output in the AI context when available. That gives the model the database's measured execution plan instead of asking it to guess from SQL text alone.
See Explain, optimize, and fix for that workflow.
MCP query plans
The built-in MCP server exposes a separate explain_query tool. By default it can request a non-analyzing plan; setting analyze: true runs EXPLAIN ANALYZE and therefore executes the query.
See MCP tools and MCP safety for limits and write protection.