Deep pagination

Key points

• from plus size is capped by index.max_result_window, default 10000.
• Asking for page 1000 makes every shard build and sort 10050 hits, then discard nearly all of them.
• search_after resumes from the sort values of the last hit, so cost does not grow with depth.
• It needs a deterministic tiebreaker in the sort, and _shard_doc is the cheapest one.
• A point in time freezes the segments, so pages stay consistent while new documents keep arriving.
• The scroll API still works but is no longer recommended for paging; it holds a search context open.

Example

POST /articles/_pit?keep_alive=2m
# -> { "id": "46ToAwMDaWR5..." }

GET /_search
{
  "size": 100,
  "pit": { "id": "46ToAwMDaWR5...", "keep_alive": "2m" },
  "sort": [ { "published_at": "desc" }, { "_shard_doc": "asc" } ],
  "search_after": [ 1754179200000, 4294967298 ]
}

from and size for shallow pages, search_after with a point in time for everything deeper.