Query plans

Turn an execution plan into useful findings, a navigable tree, or a diagram you can follow.

A query plan is the database explaining how it intends to answer your query: which indexes it uses, how it joins, and where the cost goes. SQLly turns that explanation into plain-language findings, an operator tree, and a node-and-edge diagram. One shared model keeps a PostgreSQL plan and a SQL Server plan readable in the same way.

Capturing a plan

Findings - the plan in human terms

The default view isn't a wall of operators - it's a ranked list of findings, worst first. Each one is written in plain language with a summary, a why, and a suggested action - often with ready-to-run SQL you can copy or open in a new tab, plus the technical detail one expand away.

• Table scan - “Scans every row in dbo.Orders to find matches.”
• Missing index - with a generated CREATE NONCLUSTERED INDEX statement.
• Estimate vs actual divergence - “Estimated 10 rows but read 48.2K → update statistics” (actual plans only).
• Implicit conversion, key lookup, spill to tempdb, missing statistics, cross product (no join predicate), row goals, and spools - each with its own explanation and fix.

Below the findings, an Operators list shows every operator most-expensive-first - “Index Seek — 4 rows estimated, 91% of cost, read 7” - with full per-operator detail (node id, physical/logical operator, CPU/IO cost, actual rows, warnings, output columns) on expand.

Tree & diagram

Tree view is the operator hierarchy as an indented, collapsible tree - each row showing the operator, its share of cost, estimated rows, the → actual count (highlighted when it diverges), and a ⚠ warning tally - with keyboard navigation.

Diagram view draws the plan as a top-down node-and-edge canvas. Each node is a box with the operator name, a cost% · estimated rows → actual line, and a cost bar whose length tracks the operator's cost share and turns amber when it carries a warning. Edges are drawn parent-to-child with arrowheads; you can pan the canvas and click any node to select it and see its full detail below - the same selection the tree shares.

SQLly

Batches, clean plans, and comparison

• Multi-statement batches get a per-statement tab strip - findings stay grouped by statement rather than mixed together.
• Clean plans say so plainly: “This plan looks good. No issues detected.” The Operators list is still there when you want it.
• Comparison mode keeps recent captures and diffs a baseline against a later run - highlighting operators that regressed, improved, or were added/removed - so you can prove a tuning change actually helped.
• An AI explain action hands a bounded digest of the plan to the assistant for a natural-language walkthrough.

Engine support

Every dialect is parsed into the same plan model, so findings - table scans, cost shares, estimate-vs-actual - read consistently no matter which engine produced the plan.