hardScenarioConceptMidSeniorStaff
The same statement takes 20ms in psql and four seconds from the application. Where do you look?
When the same query is fast in psql but slow from the application, first separate database time from connection wait, network transfer and ORM hydration. Then compare the real application plan, bind parameters, session settings, fetch size and result volume.
6 min readUpdated 2026-08-15
Answer
Short answer
Do not tune the SQL until you prove where the time is spent. Use database-side timing and the application's actual plan; common causes are bind-parameter generic plans, different session settings, pool wait, large result transfer and ORM object hydration.
Was this answer helpful?
Likely follow-ups
- How would you confirm that a generic plan is the problem rather than assume it?
- The application sends a string for a bigint column. What does that do to the plan?
- What is the equivalent of this problem in SQL Server, and what is the fix there?
- The query is fast for every tenant except the largest. Same cause or different?
Related questions
- A table has forty million rows, thirty-five million of them soft-deleted, and every query for active rows has got slower. Would a partial index help, and what would you have to be careful about?hardAlso on postgresql and query-optimisation5 min
- Walk me through how you read a PostgreSQL execution plan.mediumAlso on query-optimisation and postgresql5 min
- A query has an index on the filtered column but the plan shows a sequential scan. Walk me through how you would diagnose it.hardAlso on query-optimisation and postgresql3 min
- Before you tune anything, how do you decide which queries are worth your time?mediumAlso on query-optimisation and postgresql4 min