Every weekday morning, our operations team opened the dashboard and waited. The main metrics query took 14 seconds on a good day and timed out entirely on a bad one, which meant the first thing leadership saw each morning was a loading spinner and a quiet erosion of their faith in the data team. We had added indexes six months earlier to what we all assumed were the obvious columns, declared victory, and moved on with our lives. The query had quietly gotten slower as the events table grew past its teenage years, and nobody wanted to be the one to reopen it, because EXPLAIN plans make most of us break out in a cold sweat. They read like a tax form printed sideways.
I finally cornered the problem on a Thursday, not out of professionalism but out of embarrassment, because someone from finance Slacked me a screenshot of the timeout with the message 'is the company down?'. It was not. It was just our query, telling on us.
What I fed the prompt
I pasted the full query and the complete EXPLAIN ANALYZE output into the Explain a Slow Query and Suggest an Index Strategy prompt, set the dialect to PostgreSQL 15, and noted the row counts that actually mattered: events at roughly 42 million rows, users at 180 thousand. That last detail turned out to be the key to the whole diagnosis, because the planner's bad decision only makes sense once you know the relative table sizes. A nested loop is fine on a thousand rows and catastrophic on 42 million, and without the counts, even a human reviewer would not know which one they were looking at.
The thing in the plan we had all skimmed past
Gemini 3 Pro Preview's Plan Read table put the worst offender right at the top, with an estimated-versus-actual row count that was off by three orders of magnitude: a sequential scan on the 42-million-row events table that I had smugly assumed was covered by our existing index on event_type. The Root Cause section explained it in one brutal, clarifying sentence — the query filtered on event_type AND occurred_at, but combined the two conditions with an OR, and an OR across two different columns prevents Postgres from using either single-column index. We had two perfectly good indexes that the query physically could not use, all because of one logical operator that none of us had thought twice about.
This is the thing about performance bugs: the answer is almost always sitting in the plan in plain sight, but the plan is written in a dialect of pain, so we skim it, recognize nothing, and go add another index in the dark. The prompt's job is to translate the plan into the one sentence that matters.
- Recommended a composite index on (event_type, occurred_at) in selectivity order, with the reasoning for the column order spelled out so I understood it.
- Rewrote the OR as a UNION ALL of two queries, each of which could hit an index independently — the structural fix the index alone could not deliver.
- Suggested a partial index on the single most common event_type value, which alone covered about 80 percent of the actual query workload.
- Result: 14 seconds down to 120 milliseconds after applying the composite index plus the rewrite, verified against the live plan.
The section that saved us half a day
The Do NOT section said, plainly and without ceremony, that adding a standalone index on occurred_at by itself would not help, because the OR would still block it from being used. That was the exact fix our senior engineer had been about to implement — he had a branch half-written and a confident look on his face. We would have spent an entire afternoon building that index, watched the query stay stubbornly slow, and concluded 'the AI was wrong, performance tuning is dark magic,' when in fact we had ignored the one part of the answer that explicitly told us not to do the thing we were about to do. The negative advice was worth more than the positive advice.
If your dashboard has a query that the whole team is quietly afraid of, this is the prompt that makes the EXPLAIN plan legible enough to act on. Grab the Explain a Slow Query and Suggest an Index Strategy prompt on Prompt Dock, paste in your own plan and your real row counts, and let it read the part you have been skimming past for months. And when you go to write the next query, the Write a SQL Query from a Plain-English Business Question prompt will already format it cleanly enough that the resulting plan is easier to read in the first place.