A slow query does not always mean that the SQL statement is poorly written. Database teams frequently treat a slow query as an isolated SQL problem: capture the statement, inspect its execution plan and add an index. In production environments, however, the query text may be only one part of the story.
A query can run slowly because it is blocked by another transaction, processing more data than usual, using an unexpected execution plan, spilling to temporary storage, competing for limited resources or waiting on slow infrastructure. A normally fast query can also become the largest performance problem when its execution frequency suddenly increases.
This session presents an observability-driven approach to investigating slow and long-running SQL queries. Using PostgreSQL examples, it demonstrates how query statistics, execution plans, wait events, locks, logs and operating-system metrics can be correlated to distinguish symptoms from root causes.
Attendees will learn how to determine whether the problem is the SQL statement, the execution plan, workload concurrency or infrastructure.
Event
Speaker card
