Skip to content

Latest commit

 

History

History
53 lines (40 loc) · 2.07 KB

15_Pagination.asciidoc

File metadata and controls

53 lines (40 loc) · 2.07 KB

Pagination

Our empty search above told us that there are 14 documents in the cluster which match our (empty) query. But there were only 10 documents in the hits array. How can we see the other documents?

In the same way as SQL uses the LIMIT keyword to return a single `page'' of results, Elasticsearch accepts the `from and size parameters:

size

How many results should be returned, defaults to 10

from

How many initial results should be skipped, defaults to 0

If you wanted to show 5 results per page, then pages 1 to 3 could be requested as:

GET /_search?size=5
GET /_search?size=5&from=5
GET /_search?size=5&from=10

Beware of paging too deep or requesting too many results at once. Results are sorted before being returned. But remember that a search request usually spans multiple shards. Each shard generates its own sorted results, which then need to be sorted centrally to ensure that the overall order is correct.

Deep paging in distributed systems

To understand why deep paging is problematic, let’s imagine that we are searching within a single index with 5 primary shards. When we request the first page of results (results 1 to 10), each shard produces its own top 10 results and returns them to the requesting node, which then sorts all 50 results in order to select the overall top 10.

Now imagine that we ask for page 1,000 — results 10,001 to 10,010. Everything works in the same way except that each shard has to produce its top 10,010 results. The requesting node then sorts through all 50,050 results and discards 50,040 of them!

You can see that, in a distributed system, the cost of sorting results grows exponentially the deeper we page. There is a very good reason why web search engines don’t return more than 1,000 results for any query.

Tip
In [reindex] we will explain how you can retrieve large numbers of documents efficiently.