{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} {{ findingCountLabel }} {{ nodeCountLabel }} {{ formatResolutionLabel }}
Use raw PostgreSQL text or machine-readable FORMAT JSON/XML output. Source is kept out of the URL.
{{ sourceError }}
{{ fileStatus || 'Drop one TXT, LOG, PLAN, JSON, or XML file onto the textarea.' }}
Auto uses the first non-space character; pin a format when wrapper text could make detection ambiguous.
cost
×
rows
All findings is neutral; narrower views affect only the visible finding ledger and its exports.
Used only in downloaded document context; it does not alter plan evidence.
DepthNodeTargetCostRowsActualSignalsCopy
No plan nodes are available.
{{ row.depth }}{{ row.node }}{{ row.target }}{{ row.cost }}{{ row.rows }}{{ row.actual }}{{ row.signals }}
SeveritySignalEvidenceNext actionCopy
No findings match the selected display filter.
{{ row.severity }}{{ row.signal }}{{ row.evidence }}{{ row.action }}
{{ chartError.hotspots }}

No positive planner cost values to plot.

{{ chartError.drift }}

No actual row counts to compare. Supply an EXPLAIN ANALYZE plan for row drift.

MySQL Slow Query Log Analyzer Analyze MySQL slow query logs locally to group SQL fingerprints and rank accumulated or tail cost with scan, lock and temp-table findings.
SQLite Manager Open a SQLite file in your browser and inspect schema or rows before running guarded SQL and saving deliberate edits as a new local copy.
SQL INSERT Generator Turn pasted rows or a local delimited file into reviewable SQL INSERT statements with dialect-aware identifiers, literal handling, and row checks.
Database Migration Risk Checker Check SQL migration risk before release with engine and table context, exposing destructive changes plus lock hazards, rewrites and backfills.

Query tuning begins with the work PostgreSQL chose, not with the SQL text alone. An execution plan is a tree of scans, joins, sorts, aggregates, and other nodes. Indented children feed their parents, so an expensive line must be understood together with how often it runs and how many rows it passes upward.

Value What it describes Important limit
cost=a..b Estimated startup and total work in planner units Cost is not elapsed time
rows=n Estimated rows emitted by a node It does not count every row inspected
actual time=a..b Measured startup and total time per loop Loop count changes the total work
Buffers Shared and temporary block activity Cache hits and storage reads are different evidence

Plain EXPLAIN shows estimates derived from statistics, indexes, configuration, and planner assumptions. EXPLAIN ANALYZE executes the statement and adds actual rows, timing, and loops. Buffer reporting, sort-disk use, and hash batches can expose I/O or spill behavior that estimates alone cannot show.

A sequential scan is not automatically inefficient. It can be the cheapest path when a query needs much of a table, while an index scan can become costly when it returns many rows or repeats inside a nested loop. Likewise, a large estimate error is a clue about statistics, data skew, correlated predicates, or parameters rather than proof that a particular index is missing.

Plans describe one query, parameter set, schema, statistics snapshot, configuration, and data distribution. Compare before-and-after plans under equivalent conditions. Warning thresholds can prioritize review, but they cannot decide whether the workload is acceptable.

How to Use This Tool:

Capture a complete plan with its indentation or machine-readable structure intact, then choose thresholds that are meaningful for the same database and workload.

  1. Paste or load the plan. Text, JSON, and XML are accepted up to 200,000 characters. Auto detect treats an opening < as XML, { or [ as JSON, and other content as text.
  2. Pin Input format when needed. A copied wrapper or leading text can mislead automatic selection; the chosen parser must find at least one plan node with cost estimates.
  3. Set the warning values. Cost warning evaluates estimated total cost, Row drift warning compares estimated and actual rows, and Sequential scan warning uses the larger of estimated or actual emitted rows. Equality triggers all three floors.
  4. Inspect node evidence before acting on a finding. Check tree depth, relation or index, cost, rows, loops, spill signals, and buffer activity around the flagged node.
  5. Narrow Finding display only for review. The display filter hides lower-severity rows but leaves the parsed plan and the warning and critical counts unchanged.

Interpreting Results:

Critical review means at least one high-cost or row-drift rule crossed its critical multiple. Review signals means one or more warnings were found. Baseline captured means no warning or critical rule fired under the current settings. These statuses summarize a review policy, not query correctness.

  • Compare planner cost only within a consistent planner environment; do not read it as milliseconds.
  • Investigate row drift where it changes join choice, scan size, or repeated work, then check statistics and representative parameter values.
  • Treat disk sorts, multiple hash batches, and temporary blocks as spill clues. Confirm the input size and concurrent memory pressure before changing work_mem.
  • An estimate-only plan cannot confirm runtime. Collect actual evidence only when executing the statement is safe.

Technical Details:

Text plans encode hierarchy through indentation and attach details on following lines. JSON and XML carry explicit child collections and named metrics. Each path is flattened into node order while retaining depth, relation or index names, estimates, actual measurements, buffer counts, sort-disk use, hash batches, and removed rows where those values are present.

Transformation Core:

Format Tree rule Evidence read
Text Recognized node lines and leading spaces establish depth. Costs, rows, actual timing, loops, buffers, sort disk, hash batches, and removed rows
JSON A top-level Plan object is traversed through its child plans. Named numeric fields from each node
XML The first Plan element is traversed through nested plan elements. Equivalent named elements where present

YAML output is not accepted. Text parsing also depends on recognizable PostgreSQL node lines, so altered labels or heavily reformatted plans may fail even if a person can still read them.

Formula Core:

Row drift is symmetric: a tenfold underestimate and a tenfold overestimate both produce a magnitude of 10. Each row count is floored at 1 before division so zero-row nodes remain finite.

drift=max( max(1,(actual))max(1,(estimated)) , max(1,(estimated))max(1,(actual)) )

Actual rows at least as large as estimated rows are labelled underestimated; smaller actual values are labelled overestimated. A document-level execution time takes precedence. When it is absent, the root node's total time is multiplied by at least one loop. Planner cost is never converted into time.

Rule Core:

Finding Warning Critical
Highest total cost >= cost warning >= 5 × max(1, cost warning)
Row estimate drift >= row drift warning >= 10 × row drift warning
Large sequential scan Estimated or actual rows >= scan warning None
Disk-backed sort Sort disk > 0 KiB None
Hash batching Batches > 1 None
Temporary I/O Temp reads + writes > 0 blocks None

An estimate-only plan always receives an informational finding. If no configured cost, scan, spill, or drift condition fires, a baseline informational row keeps the finding set non-empty.

Safety and Privacy Notes:

Plan text and loaded files are parsed in the browser. Plans can expose schema names, table and index names, predicates, literal values, and workload shape, so remove secrets and personal data before sharing the plan or its results.

EXPLAIN ANALYZE executes the statement. A transaction followed by ROLLBACK can revert ordinary table changes, but it cannot undo every side effect, including sequence increments or external calls. Use a safe environment for data-changing or expensive statements.

References: