A query got slow after a release. Walk me through how you read the query plan and decide what to change.

Run explain analyze to get the real plan with actual row counts and timings, then look for the node consuming the most time and compare estimated rows to actual rows. A big gap means bad statistics, so the planner picked the wrong join or scan. Look for sequential scans on large tables, nested loops driven by an underestimate, and sorts spilling to disk. Fix with an index, updated statistics, or a rewritten predicate that the index can use.

I start with explain analyze and buffers so I get real timings and row counts, ideally against production sized data because a plan on a small dataset tells me nothing. Then I find the node that owns most of the time and check its estimate against the actual. If it estimated one row and got fifty thousand, the planner chose a nested loop that is now a disaster, and the underlying issue is usually stale statistics or a correlated predicate the planner cannot model. After that I look for the usual suspects: a sequential scan on a big table, a filter that could be an index condition, a sort spilling to disk, or a function wrapped around the column so the index is unusable. That last one was my most recent case, a lower call on an email column that ignored the index; a functional index on lower of email took it from about 900 milliseconds to two. Then I re run the plan to confirm the shape changed, since a faster run on a warm cache proves nothing.