Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kofi paginate changes v2 #120170

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,6 +1,18 @@
[[paginate-search-results]]
=== Paginate search results

Pagination provides a structured way for users to interact with search results by breaking them down into smaller, manageable pieces or "pages." Whether allowing users to select a specific range of pages or implementing an “infinite scroll” experience, pagination helps create a tailored and intuitive user experience.

The three commonly used pagination techniques are:

* <<from-and-size-pagination, From and size pagination>>: This method is ideal for creating a defined list of pages that users can select to navigate through the results.
* <<search-after, Search after>>: Designed for seamless navigation, this technique supports “infinite scroll” experiences or enables users to load additional results by pressing a “next” button.
* <<scroll-search-results, Scroll>>: Historically used to retrieve all matching documents for display or export. However, we now recommend using the <<search-after, search after>> method in combination with the <<point-in-time-api, point in time API>> for improved efficiency and reliability.

[discrete]
[[from-and-size-pagination]]
=== From and size pagination

By default, searches return the top 10 matching hits. To page through a larger
set of results, you can use the <<search-search,search API>>'s `from` and `size`
parameters. The `from` parameter defines the number of hits to skip, defaulting
Expand All @@ -25,14 +37,16 @@ Avoid using `from` and `size` to page too deeply or request too many results at
once. Search requests usually span multiple shards. Each shard must load its
requested hits and the hits for any previous pages into memory. For deep pages
or large sets of results, these operations can significantly increase memory and
CPU usage, resulting in degraded performance or node failures.
CPU usage, resulting in degraded performance or node failures if not managed correctly.

By default, you cannot use `from` and `size` to page through more than 10,000
hits. This limit is a safeguard set by the
<<index-max-result-window,`index.max_result_window`>> index setting. If you need
to page through more than 10,000 hits, use the <<search-after,`search_after`>>
parameter instead.

Pagination is stateless, meaning there is no guarantee that the order of search results will remain consistent when users navigate back and forth between pages. If maintaining consistent result order is desired, the preferred approach is to use the <<point-in-time-api, point in time (PIT) API>> to implement a stateful pagination technique.

WARNING: {es} uses Lucene's internal doc IDs as tie-breakers. These internal doc
IDs can be completely different across replicas of the same data. When paging
search hits, you might occasionally see that documents with the same sort values
Expand All @@ -43,7 +57,7 @@ are not ordered consistently.
=== Search after

You can use the `search_after` parameter to retrieve the next page of hits
using a set of <<sort-search-results,sort values>> from the previous page.
using a set of <<sort-search-results,sort values>> from the previous page. This approach is ideal for scenarios where users click a "next" or "load more" button, rather than selecting a specific page.

Using `search_after` requires multiple search requests with the same `query` and
`sort` values. The first step is to run an initial request. The following
Expand Down
Loading