Section 2 of 3 · 7 minutes
Recognise checkpoint pressure
Your goal
What you will be able to do
Use checkpoint timing and write statistics to test whether checkpoints match an IO spike.
Why this matters at work
The practical reason
A poorly paced checkpoint can create repeating latency even when average storage use looks acceptable.
Learn
The idea in plain English
A checkpoint makes dirty data pages reach storage and records a recovery point. Checkpoints occur because of time, WAL volume, or explicit requests.
Compare checkpoint counts, write time, sync time, and host storage latency over the same interval. A repeating pattern is stronger evidence than one slow query near a checkpoint.
Remember these points
- Checkpoint work writes dirty pages over a controlled interval.
- Compare PostgreSQL and storage evidence with matching timestamps.
- More frequent checkpoints can increase full-page-image WAL volume.
See it in SQL
Read checkpoint statistics
Measure checkpoint frequency and time spent writing and syncing.
SELECT
num_timed,
num_requested,
write_time,
sync_time,
buffers_written,
stats_reset
FROM pg_stat_checkpointer;Requested checkpoints can point to WAL pressure or explicit requests; timed checkpoints follow the timeout schedule.
Use differences between samples because these counters are cumulative.
Cumulative timed and requested checkpoint counts, write/sync time, buffers written, and reset time.
Useful words
Important terms
- Checkpoint
- A recovery point that ensures required dirty pages are written to durable storage.
Quick check · Not graded
Check your understanding
What best supports a checkpoint-pressure diagnosis?
Your progress is saved to your signed-in account.