Section 2 of 3 · 7 minutes

Test the most useful cause

Your goal

What you will be able to do

Choose one likely cause that can be confirmed or rejected with safe, time-aligned evidence.

Why this matters at work

The practical reason

Collecting unrelated metrics wastes the recovery window and encourages changes that do not test anything.

Learn

The idea in plain English

Use the symptom and recent changes to choose the next question. Slow queries may need activity, wait, plan, and workload evidence. Blocked writes need a blocking chain. Disk growth needs table, WAL, log, and temporary-file evidence.

Write what result would support or reject the cause before running the query. Use read-only checks first and timestamp the result.

Remember these points

Ask one diagnostic question at a time.
Name the result that would support or reject it.
Use time-aligned PostgreSQL and system evidence.

See it in SQL

Find current waits

See whether active sessions are waiting and what resource class they report.

SELECT
  pid,
  application_name,
  state,
  wait_event_type,
  wait_event,
  now() - query_start AS query_age
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY query_start;

Wait fields help separate lock, client, IO, and other waits. A null wait does not mean the query is fast; it may be using CPU.

Connect PIDs back to the application and query plan before acting on a session.

What you should see

Non-idle sessions ordered by start time with their application, wait class, wait name, and age.

Useful words

Important terms

Hypothesis: A possible cause stated so evidence can support or reject it.

Quick check · Not graded

Check your understanding

What makes a diagnostic hypothesis useful?

Choose one answerIt cannot be disproved by any result.It names the evidence that would support or reject one possible cause.It requires several changes before any measurement.

Your progress is saved to your signed-in account.