Job query-slow-query-fixed-with-explain-evidence · revised 11 October 2026
Make one slow database query fast, with before and after plan evidence
One slow PostgreSQL or MySQL query meets a time you set on a staging copy, with the before and after execution plans and an identical-rows check attached.
You might be seeing
- One report, page or API call times out or takes several seconds
- The same statement appears at the top of the slow query log or of total execution time in statement statistics
- The query was fast when the table was small and slowed as rows accumulated
No passwords, keys, card details or admin invites needed to start.
What usually happened
A single SQL statement spends most of its time reading far more rows than it returns, sorting or joining inefficiently, or running a plan chosen from out-of-date statistics. The plan can be read and its cost measured on a copy, but nobody has traced which step is expensive or whether the fix is the statement, an index or the statistics. This is one statement on one database, not general slowness, a hardware limit or a many-queries-per-request pattern.
Who it’s for: An engineering manager or founder whose page, report or API call waits on one database query that can be named and pasted.
Usually starts when: One statement tops the slow query log or the statement-statistics view, or one screen takes seconds because of it, and nobody on the team has time to read its plan.
The result: The named query returns the same rows as before, in the time you set, on a staging copy of realistic size. You receive its before and after plans with actual timings, the change that made the difference and a script that undoes it.
Check whether this job fits
Answer these without sharing credentials, data or code. The result is a fit check, not permission for us to connect to anything.
Checks you can run yourself
Read the plan without running the statement
In a database console connected to a copy, put EXPLAIN in front of the query. Plain EXPLAIN shows the plan without executing the statement. Do not add ANALYZE to an INSERT, UPDATE or DELETE, because ANALYZE runs the statement for real.
EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at DESC LIMIT 20;Look for: A sequential scan (PostgreSQL) or access type ALL (MySQL) on a large table that returns few rows, or a separate sort step on many rows. Send the plan text with invented values.
What you get
- A pull request or script containing the rewritten statement and any index definitions, plus a script that removes the indexes again
- The before and after execution plans as plain text, with a short note on what each shows
- A result comparison showing the rows returned are identical for every agreed parameter set
- A note on write cost: what any new index does to inserts and updates on the same table
Included
- One named query on one PostgreSQL or MySQL database, supplied with invented or redacted parameter values
- Read its plan with actual row counts and timings on a staging copy, and find the step that costs the most
- Fix it with the smallest change the plan supports: a rewrite of the statement, up to two new or changed indexes, or a statistics refresh
- Repeat the same measurement on the same data and compare result rows, plan and time before and after
Not included
- Running any change against your production database; you apply it yourself after a restore point you have tested
- More than one query, or a review of every slow statement in the database
- Server sizing, configuration tuning, a database engine change or adding a cache
- Statements that are slow because they wait for locks or connections rather than read data
- A guarantee of the same speed in production, where data volume, cache state and load may differ from the staging copy
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
On the staging copy the named query meets the target time you set for every agreed parameter set, taken as the median of at least five repeated runs.
Evidence: Before and after timings for each parameter set as plain text, with the run count and the data volume used.
The changed query returns exactly the same rows as the original for every agreed parameter set.
Evidence: A result comparison (row count and a checksum of the ordered rows) for each parameter set.
The before and after plans show the expensive step has changed, with estimated and actual row counts for that step.
Evidence: Both plans as plain text, with a note naming the step.
Any added index has a script that removes it, and its effect on insert and update time for the same table is measured and reported.
Evidence: The undo script and the write-cost comparison.
Sign-off. You compare the plans and timings, repeat the rows check yourself if you wish, and sign off in writing. Payment follows sign-off; applying the change to production stays your decision.
If it fails. If the agreed target is not met on the staging copy, you do not pay for this fixed scope and you keep the plans and findings. If the cause lies outside the query, we explain what we found and stop.
When it fits, and when we stop
It fits when
- A PostgreSQL or MySQL database on a version you can name; we confirm at intake that plan measurement with actual timings is available on it
- You can supply the query text with invented or redacted values, and say which database it runs on
- A staging copy exists or can be restored from a backup, with realistic row counts and with personal data removed or replaced
- An engineer on your side can review the change and apply it under your release process
We stop and tell you if
- The query is fast on the staging copy and slow only in production, and the cause is load, locking or cache state that cannot be reproduced
- The slow step is outside the database, such as network transfer, an application loop or serialisation; we report that and stop
- The staging copy is too small or too unlike production for the plan to mean anything and no better copy can be prepared
- The only fix would change what the query returns or needs a schema redesign; that is quoted as a separate job
What could go wrong
Index changes arrive with a script that removes them, and a rewritten statement is an ordinary code change you can revert. We apply nothing to production, so until you choose to apply the change the previous behaviour is untouched.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A new index speeds the query but slows writes on a busy table. | We measure insert and update cost on staging and report it, and you decide whether the trade is acceptable. |
| The plan is good on the copy but production data distribution or load differs. | Acceptance names the copy used and does not promise production timing. We give a way to check the plan on a replica or in a quiet window. |
| A rewrite quietly changes which rows come back. | Acceptance compares the rows for every agreed parameter set, including empty and edge cases. |
A second reviewer reads the plans, the diff and the before and after measurements, and checks that no data-changing statement is aimed at your production database. Your engineer reviews and applies the change under your own release process.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the query, the engine, the target time, the invented parameter sets and the staging copy in writing
- Record the baseline on the staging copy: the rows returned, and the plan with actual timings, over repeated runs
- Find the step that costs the most, and check statistics, index fit and statement shape before proposing a change
- Apply the smallest change on staging; confirm the same rows come back and the plan changed for the reason expected
- Repeat the measurement the same way, and measure insert and update cost on any table that gained an index
- Independent review of the plans, diff and measurements, then hand over the change, the undo script and the notes
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access and any permissions are in place. Hosting and database charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
Discuss a monthly review of slow statements and table growth if you want someone to keep watching for the next one.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Your own engineer can read the plan using the PostgreSQL guide to EXPLAIN, which explains estimated and actual row counts and when a sequential scan is the right plan. www.postgresql.org
- On MySQL, EXPLAIN ANALYZE runs the statement and shows the optimizer's estimates beside the actual rows and timings. dev.mysql.com
Questions
Will you run EXPLAIN ANALYZE on my live database?
No. EXPLAIN ANALYZE executes the statement, so we measure on a staging copy that you prepare. We never connect to production.
What if the fix turns out to be no index at all?
A sequential scan is sometimes the right plan, for example when most of the table is read. We then say so and look at the statement or the statistics instead of adding an index for its own sake.
My slowness comes from many small queries on one page. Does this fit?
Not as one statement. Many queries per request is a different failure, covered by the one-endpoint query-count job.
Send an enquiry
Send us
- The query text with parameter values replaced by invented ones, and the database engine and version
- The plain EXPLAIN output for that query (without ANALYZE), with only table names you are content to share
- Approximate row counts of the tables involved, and how long the query takes today
- Do not send credentials, a dump, real customer values or a connection string in the first enquiry
Later, once you agree
- A staging database restored from a backup, with personal data removed or replaced, and a read-write connection to it that is not production
- The code that issues the query, through an authorised company-controlled repository route, if the fix is a rewrite there
- The target time and the invented parameter sets used to measure it, agreed in writing
- Who will review and apply the change, and the restore point they will use in production
You own the database, the code and every credential. We work on a copy you prepare, such as a staging database restored from a backup with personal data removed or replaced, and we hand work back as a pull request or a script. We never ask for production passwords, and we do not connect to your production database. You apply any change to production yourself, after a restore point that you have tested.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “query-slow-query-fixed-with-explain-evidence” as the subject.