Fix the slowest query on one endpoint
The query that dominates one endpoint's latency, fixed with the plan captured before and after.
The ticket
Reduce the latency of the slowest query behind one endpoint.
Acceptance criteria
- The plan and timing are captured before and after
- The fix is an index, a rewrite, or fewer round trips rather than a cache over the top
- Results are identical, proven by a test
- The improvement is measured on production-like data volumes
What lands as proof
Two query plans and two timings, taken against realistic data rather than a small development dataset.
Why teams defer it
- It is fast on a development database with a thousand rows, so it passes review comfortably.
- Fixing it properly needs production-like data, which the person doing the work often cannot get.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: reduce the latency of the slowest query behind one endpoint. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means query plan and timing captured before and after, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops once the plan is written. Somebody reads the approach and approves it before any code exists, which is the cheapest moment to redirect the work.