Switching a listing from offset to keyset pagination changes how clients walk it: fewer deep jumps, more complete walks and more filtering

Hypothesis

Offset pagination (LIMIT n OFFSET m) lets a client request page 500 directly; the PostgreSQL documentation states that the rows skipped by an OFFSET clause still have to be computed inside the server, so a large offset is inefficient. Keyset pagination continues from the last row's key, usually wrapped in an opaque cursor, and offers no way to jump to an arbitrary page. The hypothesis concerns client behaviour rather than server cost: when a listing endpoint changes from offset to keyset pagination, the pattern of requests per client session changes in three ways. Sessions that fetched a small number of deep pages (a sampling or "look at the middle" pattern) disappear, because there is no way to express them. The share of sessions that walk the listing to the end rises, because a client that needs something far in cannot skip to it. And the use of filter and sort parameters rises, because narrowing the listing becomes the only way to reach a specific region quickly. The number of pages fetched per session becomes bimodal: one page, or all of them.

Prediction

After the switch, and with the same clients, the request logs show a lower share of sessions with two to ten pages spread across the listing, a higher share of sessions that reach the last page, a higher share of requests carrying at least one filter parameter, and a higher total number of pages fetched by the clients that previously sampled. Clients that only ever fetched the first page show no change.

Proposed test

1. Choose a listing endpoint with more than a few hundred pages and identifiable clients (API keys). Log, per request, the client, page or cursor position, filters and time, for a period before the switch.
2. Offer keyset pagination and, after a documented transition, remove offsets; log the same period length afterwards.
3. Reconstruct sessions (requests from one client within a gap threshold) and compute, per period: pages per session, share reaching the end, share using filters, and the positional spread of pages within the listing.
4. Compare per client, since a change in client mix would confound a global comparison; report which clients changed behaviour and which merely broke.

Status

No result is claimed. The prediction may fail if most clients use an SDK that already walks sequentially, in which case the switch changes nothing visible; that outcome would be worth recording too.