Pagination: from/size, search_after and Point in Time

Why deep pages are expensive

from and size are fine for the first few pages, but every shard must collect from + size hits and the coordinating node must sort them all, so cost grows with depth. Elasticsearch limits from + size to index.max_result_window (default 10,000). For deep or "load more" pagination, use search_after: sort on fields with a unique tiebreaker and pass the sort values of the last hit to get the next page. To keep pages consistent while data changes, open a point in time (PIT), which freezes a view of the index; search with the PIT id (no index in the path) and keep it alive with keep_alive. The scroll API is no longer recommended for deep pagination; PIT plus search_after replaces it.

Beyond the first page of results

Real search UIs need stable pagination, highlighted snippets, suggestions while typing and, increasingly, semantic matching.

Point in time with search_after

Kibana Dev Tools console syntax; send the same requests with curl or a client library.

POST /products/_pit?keep_alive=1m
# -> { "id": "<pit-id>" }

GET /_search
{
  "size": 50,
  "query": { "match": { "name": "jacket" } },
  "pit": { "id": "<pit-id>", "keep_alive": "1m" },
  "sort": [ { "price": "asc" }, { "_shard_doc": "asc" } ]
}

# next page: pass the "sort" array from the last hit of the previous page
GET /_search
{
  "size": 50,
  "query": { "match": { "name": "jacket" } },
  "pit": { "id": "<pit-id>", "keep_alive": "1m" },
  "sort": [ { "price": "asc" }, { "_shard_doc": "asc" } ],
  "search_after": [ 79.9, 1234 ]
}

DELETE /_pit
{ "id": "<pit-id>" }

Users rarely need page 500

Cap UI pagination (for example 50 pages) and offer better filters instead. Use PIT and search_after for exports and background jobs that genuinely walk everything.

त्वरित जाँच: What is the recommended way to page deeply through results?

• Raising max_result_window to millions
• from and size with a large from
• search_after with a point in time
• One query per shard