How to Discuss a Slow Query Plan with a DBA in English

Talking to a database administrator (DBA) about a slow query requires a specific vocabulary — you’re not just saying “it’s slow,” you’re describing what the query planner chose to do and why that choice might be wrong. This guide covers the English phrasing for discussing query plans, index usage, and optimization proposals clearly.

Key Vocabulary

Query plan — the sequence of steps the database engine chooses to execute a query, including which indexes it uses and in what order it joins tables. “Can you take a look at the query plan for this report query? It’s choosing a sequential scan where I’d expect an index scan.”

Sequential scan (seq scan) — reading every row in a table to find matches, which is usually slow on large tables and often a sign a useful index is missing. “The planner is doing a sequential scan on a 40-million-row table, which explains why this query takes 12 seconds.”

Index scan — using an index to jump directly to matching rows instead of scanning the whole table, which is typically much faster for selective queries. “Once we added the index on created_at, the plan switched to an index scan and the query dropped to under 100ms.”

Cardinality estimate — the database’s guess at how many rows a step in the query will return, which strongly influences which plan it chooses. “The planner’s cardinality estimate for this join is way off — it expects 200 rows but the actual result is 2 million, which is why it picked a nested loop instead of a hash join.”

Statistics (table statistics) — metadata the database keeps about the distribution of values in a table, used to produce cardinality estimates; stale statistics often cause bad plans. “Statistics on this table haven’t been updated since the last bulk import, so the planner is working from outdated assumptions. Can we run an analyze before we look at this further?”

Common Phrases

• “Here’s the EXPLAIN ANALYZE output — the planner is choosing a seq scan on the orders table.”
• “Actual rows returned is way higher than the estimate, which suggests the statistics are stale.”
• “Would adding a composite index on (customer_id, created_at) help here?”
• “This join is a nested loop over 2 million rows — that’s probably our bottleneck.”
• “Can we run ANALYZE on this table before we dig further into the plan?”

Example Sentences

Opening a conversation with a DBA by sharing concrete evidence: “I ran EXPLAIN ANALYZE on this query and it’s spending 9 of its 11 seconds on a sequential scan of the events table. Would you be open to discussing whether an index on (user_id, event_type) makes sense here?”

Describing a mismatch between estimate and actual: “The planner estimates this join will return about 500 rows, but EXPLAIN ANALYZE shows it actually returns 1.2 million. That gap is probably why it’s choosing a nested loop instead of a hash join.”

Proposing a specific next step rather than a vague complaint: “Rather than just flagging that this is slow, I’d like to propose we test a composite index and compare the plan before and after — I can put together a before/after EXPLAIN ANALYZE comparison if that’s useful.”

Following up after a fix: “After adding the index, the plan now uses an index-only scan and the query time dropped from 11 seconds to 80 milliseconds. I’ve attached the before and after plans for reference.”

Professional Tips

• Always bring the actual EXPLAIN ANALYZE output, not just a description — DBAs will want to read the plan themselves, and pasting it shows you’ve already done the diagnostic work.
• Use “the planner chose” or “the planner is choosing” rather than “the database is doing” — this framing correctly attributes the decision to the query optimizer, which is what the DBA will actually be reasoning about.
• Point out the gap between estimated and actual rows explicitly when you see one — it’s one of the most common root causes DBAs look for first.
• Propose a specific, testable next step (“test a composite index on X”) rather than just describing the problem — it shows you’re offering a hypothesis, not just asking someone else to fix it.
• After a fix, share the before/after comparison — it closes the loop and helps build a shared understanding of what worked.

Practice Exercise

1. Write a sentence opening a conversation with a DBA that includes a specific number from EXPLAIN ANALYZE output.
2. Write a sentence describing a gap between estimated and actual row counts.
3. Write a follow-up message reporting the before/after result of an index change.