Page two of the delivery log

Constraints

1. 1Newest first, by delivered_on descending.
2. 2Five rows per page, and this is page 2.
3. 3The ordering must be total: no two rows may compare as equal, or the engine is free to return them in a different order on the next run and the page boundary moves with it.
4. 4Break ties on delivery_id descending, which keeps newer ids above older ones within a day and is unique by definition.
5. 5Return delivery_id, city, delivered_on and minutes.

Worked example

Twenty-six deliveries share only five dates, so ORDER BY delivered_on DESC leaves large groups of rows tied. Four deliveries — 25, 24, 16, 8, 7 — all completed on 2026-03-04, and nothing in that ORDER BY says which comes first. Page 1 takes five of them in whatever order the engine produced. Page 2 skips five and takes the next five — but if the engine ordered the tied rows differently on the second query, the two pages are cut from two different lists. A row can appear twice, and a row can vanish. Adding delivery_id DESC makes the sort total, so page 1 ends at delivery 25 and page 2 begins at delivery 24 every single time.

What this tests

Whether you know that LIMIT and OFFSET are meaningless without a deterministic sort — the single most common pagination bug in production.