Query plan

Summarize a database plan around its costly operators and evidence.

Condense a supplied database execution-plan discussion into a short evidence-based reading. Select this for query operators and row flow, not general benchmark reporting.

Identify the query or supplied label, database version, and whether the plan is estimated or executed. Keep operators that explain cost, actual timing, row-estimate errors, repeated loops, sorting, spills, and filtering. Retain exact table, index, and predicate names. Distinguish planner cost units from elapsed time and per-loop values from totals.

Collapse uninformative plan scaffolding and repeated commentary. Preserve cache state, parameter values, and measurement conditions that limit the result. State a suspected bottleneck as a suspicion unless the evidence establishes it. Keep proposed changes separate from measured outcomes.

Output Query, Evidence, and Interpretation lines, with a proposed next check only if supplied. Do not execute SQL, recommend a destructive change, invent an index, or claim that a suggested rewrite improved performance without a measured comparison.

Example

Filtered order lookup

Before 101 words

For query Q7 on PostgreSQL 16, EXPLAIN ANALYZE was run once with a warm cache and customer_id = 42. The plan used a sequential scan on orders. The scan estimated 100 matching rows but returned 18,000 actual rows and removed 982,000 rows by the filter customer_id = 42. Total execution time was 186 ms. The result then used an in-memory quicksort, so there was no disk spill. The scan appears to be the main cost, but this is only one parameter value and one warm-cache run. We proposed testing an index on orders(customer_id); that index has not been created or measured.

After 53 words

Query: Q7, PostgreSQL 16; one warm-cache EXPLAIN ANALYZE run; customer_id = 42. Evidence: orders sequential scan estimated 100 matches; actual 18,000, with 982,000 rows filtered out. Execution: 186 ms. In-memory quicksort; no spill. Interpretation: Scan appears dominant; one parameter and run limit the finding. Next check: Proposed orders(customer_id) index; not created or measured.

Examples illustrate the method. They do not measure model output.

Files and sources

prompt.txt Complete prompt as plain text.
SKILL.md The same prompt with a skill header.
llms.txt (JSON) Prompt, metadata, example, and sources.
LICENSE MIT license text.

An original sho.rten.it skill. Source notes.