Version 1 of 1 · published Sep 8, 2026Version 1 · only version
Score 0
Creates a private draft copy of “Triage a slow SQL query using its real execution plan” that credits the original. You'll add your own example result before publishing.
Example output
No public result for version 1 yet
Nobody has shared what a model actually produced from this exact version, and PromptByte never generates examples itself. Run the prompt and add yours to fill this in.
Fill in the values below — the customized prompt updates as you type.* marks a required value.
Engine/version, workload and measured symptoms. Default: PostgreSQL 16; weekly reporting query; measured around 2 seconds on a staging copy.
Query, relevant keys, indexes and table sizes. Default: SELECT customer_id, count(*) FROM orders WHERE created_at >= DATE '2026-08-01' GROUP BY customer_id;
orders(id bigint primary key, customer_id bigint, created_at timestamptz);
Actual EXPLAIN output and observed timings, or explicit missing evidence. Default: No execution plan captured yet. The table contains approximately 2 million rows.
Customized prompt
live preview
Resolved user prompt12 lines
Investigate this slow query.
Database and workload: PostgreSQL 16; weekly reporting query; measured around 2 seconds on a staging copy.
Query and schema: SELECT customer_id, count(*) FROM orders WHERE created_at >= DATE '2026-08-01' GROUP BY customer_id;
orders(id bigint primary key, customer_id bigint, created_at timestamptz);
Execution plan and measurements: No execution plan captured yet. The table contains approximately 2 million rows.
Restate the required result and current measured baseline. Walk through the supplied plan, distinguishing estimated rows from actual rows and identifying costly operations, loops, sorts, or cardinality surprises supported by the evidence.
Propose at most three experiments. For each, state the hypothesis, a minimal query or index change, correctness risks, write/storage tradeoffs, and the before/after measurement needed. Preserve filtering, null, duplicate, and ordering semantics.
If no plan is supplied, request the minimum useful plan information rather than simulating costs. Note that execution-based plan commands run the query and should be used only in a suitable environment. Do not invent speedups or recommend dropping indexes from one query alone.
Converts a natural-language data requirement plus a table schema into a syntactically correct SQL query for a named database, with its assumptions stated up front.