Code
Tune a slow query
Read the plan, find the real cost, and prove the fix with numbers.
Fill it in
Paste it, with the schema if you have it.
If you already have one.
Same data, same conditions.
Your prompt
Tune this query. [the query] Existing plan: [your explain output] Run EXPLAIN ANALYZE and read the actual rows against the estimated rows. That gap is where nearly every slow query lives: the planner chose a nested loop expecting 12 rows and got 400,000, and no amount of index guessing fixes a bad estimate. Find the one node that dominates the time before changing anything. Optimising a step that costs 3% of the runtime is the most common wasted afternoon in this work. Measure before and after on the SAME data with a warm cache both times. A comparison against a cold run is how a query that got slower gets shipped as a fix. Say what the index costs on write, and whether the query should exist at all.
Use Tune a slow queryOpens with everything above already filled in.
Why this works
Nearly every slow query is a bad row estimate: the planner expected 12 rows and got 400,000, and no amount of index guessing fixes that. This reads actual against estimated, finds the node that dominates, and measures both runs warm.