Investigate a slow query step by step ​

Begin with the exact query, representative data and the result the reader actually needs. A slow request can be expensive SQL, a large result or delayed response delivery. Do not change several limits before identifying which observation supports the diagnosis.

First inspect the access plan without executing a write:

EXPLAIN QUERY PLAN
SELECT id, amount FROM orders WHERE id = 42;

Then retain the real execution's query ID and read its terminal history. Compare duration, read rows, returned rows and peak accounted memory. Active elapsed includes the request's lifetime through response delivery, so it answers a different question from a plan measurement.

Check whether the query projects unnecessary columns, joins duplicate keys or requests rows that the caller never uses. A targeted index can help a repeated lookup, but verify its chosen access path and write overhead with the actual workload.

Finally, inspect effective settings if a request fails at a resource limit. Raising a ceiling is a deliberate operational choice, not evidence that the query became more efficient.

See query measurements, indexes and effective settings.