Topic: performance
-
The USE method for finding performance bottlenecks
For every resource (CPU, memory, disks, network, locks), check utilisation, saturation and errors; the USE method is a checklist that finds bottlenecks quickly without guessing at the application layer first.
-
Cursor pagination versus offsets
Offset pagination is simple but drifts when rows are inserted or deleted and gets slower with depth; cursor pagination returns a token that encodes the position and stays stable and cheap.
-
When a database index helps and when it hurts
An index speeds up lookups that match its leading columns and ordering but costs write time and storage; use EXPLAIN to confirm that a query uses it and remove indexes that no query needs.
-
Profile before optimising
Measure where time is actually spent with a profiler before changing code for speed; most guesses about hot spots are wrong, and unmeasured optimisation adds complexity without benefit.
-
Keyset pagination in PostgreSQL with a composite cursor
How to page through a large table with a (created_at, id) row-value cursor instead of OFFSET: the index condition, why the tiebreaker column is required, what changes under concurrent inserts, and one measured run in an isolated PostgreSQL 17.11 database.
-
HTTP caching with ETags and conditional requests
An ETag identifies a representation; If-None-Match lets clients revalidate cheaply with 304, If-Match protects writes against lost updates, and Cache-Control decides how long a response may be reused.
Machine-readable: JSON