Follow one slow customer action into PostgreSQL. Distinguish the query's work from its waits before choosing what to change.
João Dezembro · 3 min
More in EngineeringTo diagnose a slow PostgreSQL query, connect one slow customer action to its database operation and inspect what happens during the delay. Compare the query plan with evidence of execution or waiting, using representative inputs and concurrent work. Choose a change only when those observations support it, then check both elapsed time and the result the customer receives.
A customer waits when assigning a ticket, but the team cannot explain where the time goes. That is a useful starting point. Saying the database has become slow leaves too many different operations in the same problem.
Keep the action, time window and relevant data conditions together. Ask what the application timing covers: acquiring a connection, sending the request, query execution or the whole call. A slow database call does not, by itself, distinguish those boundaries.
Record an observation or an explicit unknown before proposing an intervention.
| Question | Evidence and next check |
|---|---|
| Which operation is slow? | Match the customer action to the statement and time window. Keep representative inputs and data conditions without unnecessarily copying sensitive values. |
| What does the plan suggest? | Ask an engineer to inspect EXPLAIN for the affected input. Treat its costs as estimates of work, not measured milliseconds or proof that a scan is wrong. |
| What happens during the delay? | Correlate the operation with activity and wait evidence. An active backend can still be waiting. One brief sample may miss the condition. |
| What would distinguish the explanations? | Choose a controlled measurement with the responsible engineer. EXPLAIN ANALYZE runs the statement, so decide the safe environment and effects before using it. |
| Did the change address this case? | Repeat the action with relevant data and concurrent work. Compare elapsed time and the final record, and keep the conditions with the result. |
Imagine the assignment updates a ticket while another transaction has already updated that same row and remains open. The assignment waits. An isolated execution plan might look inexpensive because it does not reproduce that competing transaction.
If observations during the delay identify this conflict, the next question is why the holding transaction stays open and what operation it protects. Investigate that boundary before changing infrastructure. After a correction, repeat the competing work and check that the ticket has the intended owner. This hypothetical example does not establish the cause of your slowdown.
Some waits protect the correctness of concurrent work. Removing that protection can create a different problem. Ordinary row locks also do not block a plain reading query in the same way as a conflicting update. The statement and lock mode matter.
Use documentation for your PostgreSQL version and qualified access to the relevant measurements. A passing run supports its tested conditions; it does not explain every future slowdown or prove that a larger database is unnecessary.
Start with the action, observed delay and evidence already available. Gridfused can help investigate the bottleneck and implement a change that can be checked against that case.
Founder & Managing Director
Founder of Gridfused Technologies. Software architect and engineering leader focused on building reliable products, systems, and AI-enabled operations.
November 2, 2026
3 min
Categories
