Use ChatGPT for SQL optimization with a query plan and a fair comparison

The workflow is to establish a baseline, identify a plausible bottleneck, test a bounded change, and compare both results and performance under comparable conditions. The examples here use PostgreSQL; use your database version's own plan commands for another engine.

Collect the evidence behind the slow query

Record the slow parameter values, expected output, representative data size, current indexes, and database version. Include what “slow” means: database execution, fetching many rows, or rendering the result in an application. A database plan cannot explain every part of a page's response time.

In PostgreSQL, plain EXPLAIN shows the planned operations and estimates. EXPLAIN ANALYZE executes the statement and adds observed information. Plan costs are planner units, not milliseconds. Review these distinctions in the PostgreSQL EXPLAIN documentation, checked October 24, 2026.

Collect execution evidence in an approved environment with appropriate limits. Do not run an expensive query on production simply because a chat suggests it. In particular, adding ANALYZE to a data-changing statement runs that statement; plain plan inspection and execution are different actions.

Help diagnose this PostgreSQL query. Do not change the database.
Version: [VERSION]
Query and representative parameter values: [PASTE]
Schema, keys, existing indexes and approximate table sizes: [PASTE]
Plan output and how it was obtained: [PASTE]
Expected output rules: [PASTE]
Measured baseline and test conditions: [PASTE]

Separate plan observations from hypotheses. Identify the strongest
bottleneck supported by the supplied evidence and propose one change
to test. Explain how it could affect nulls, duplicates, ordering and
boundary values. Name missing evidence before recommending an index
or schema change. Do not invent timings or claim a speedup.

OpenAI's prompting guidance supports providing the actual task context and boundaries. The useful output here is a testable diagnosis, rather than a list of generic tuning rules.

Test a date-filter rewrite without changing the question

This original fictional query uses a timestamp without time zone column holding local appointment times:

SELECT appointment_id, starts_at
FROM appointments
WHERE starts_at::date = DATE '2026-10-24'
ORDER BY starts_at, appointment_id;

A candidate rewrite compares the column directly with a half-open range:

SELECT appointment_id, starts_at
FROM appointments
WHERE starts_at >= TIMESTAMP '2026-10-24 00:00:00'
  AND starts_at <  TIMESTAMP '2026-10-25 00:00:00'
ORDER BY starts_at, appointment_id;

Check the intended date boundaries before timing it:

Direct comparisons can make an ordinary index on starts_at relevant, but the actual plan must show what happens. The planner may reasonably choose a sequential scan for a small table or a large matching fraction. An expression index or other workload conditions can also change the comparison. No speedup is asserted for this unexecuted teaching example.

For timestamp with time zone, first establish the business time zone and the actual instants defining its day. Do not copy these local timestamp boundaries into a different time-zone requirement and assume equivalence.

Compare results before accepting performance

Compare full result values and duplicate counts, not only the number of rows. Preserve ordering when the consumer relies on it. For aggregate queries, include empty groups and null inputs in the comparison. If the query already produces wrong totals, resolve the SQL counting rules before optimizing it.

Then compare execution evidence using the same representative parameters and comparable data and load. Note warm-cache effects and run-to-run variation. A faster second run alone cannot establish that a rewrite caused the improvement.

Keep the original query, candidate, result comparison, plans, and measured conditions together. Ask the database owner to review any index proposal with its storage and write costs. Accept the change only after its actual results remain correct and the measured behavior supports the reason for making it.