Skip to content

Opster paginate changes rebase #123674

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.

Sign up for GitHub

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

Merged
merged 3 commits into from
Mar 1, 2025
Merged

Opster paginate changes rebase #123674

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6cd90e1
This is a copy from the original ticket https://github.com/elastic/el…
thekofimensah Feb 28, 2025
40deca3
Update docs/reference/search/search-your-data/paginate-search-results…
georgewallace Feb 28, 2025
d1db65b
Merge branch '8.17' into 8.17
georgewallace Feb 28, 2025
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
20 changes: 17 additions & 3 deletions docs/reference/search/search-your-data/paginate-search-results.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,18 @@
[[paginate-search-results]]
=== Paginate search results

Pagination organizes search results into manageable pages, enhancing user interaction. Whether selecting specific page ranges or using infinite scroll, pagination offers a tailored user experience.

The three commonly used pagination techniques are:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Pagination organizes search results into manageable pages, enhancing user interaction. Whether selecting specific page ranges or using infinite scroll, pagination offers a tailored user experience.
The three commonly used pagination techniques are:
{es} uses pagination to segment large result sets into manageable pages for efficient retrieval and processing.
{es} supports three pagination techniques:

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original read a little marketing-y and direct voice is clearer :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do agree that maybe it sounds a bit marketing-y. However I think something that a lot of our documentation is missing is a helpful introduction to a topic. I.e. starting out telling the user exactly what the feature is used for and how it can help them rather than a technical overview

I think the rewrite optimizes clarity and concision and but it's not as helpful. Also elasticsearch doesn't use pagination, the engineer does.

This rewrite is trying to be less marketing-y:

"Pagination splits large search result sets into smaller pages, making them easier for users to navigate. You can implement it to let users jump to specific page ranges (e.g., 'Page 1, 2, 3') or use an infinite scroll method where more results load as the user scrolls.

{es} supports three pagination techniques:"

@leemthompo @georgewallace

Copy link
Contributor

@leemthompo leemthompo Mar 3, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do agree that maybe it sounds a bit marketing-y. However I think something that a lot of our documentation is missing is a helpful introduction to a topic.

I don't disagree but the original intro sentence wasn't helpful because it was long on verbiage and short on facts.


* <<from-and-size-pagination, From and size pagination>>: Ideal for creating a list of pages that users can navigate.
* <<search-after, Search after>>: Supports infinite scroll or allows loading additional results with a "next" button.
* <<scroll-search-results, Scroll>>: Historically used to retrieve all matching documents. The <<search-after, search after>> method with the <<point-in-time-api, point in time API>> is now recommended for better 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. If not properly managed, these operations can result in degraded performance or node failures.

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, so search result order may change when navigating between pages. To maintain consistent order, use the <<point-in-time-api, point in time API>> for stateful pagination.

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 Expand Up @@ -629,4 +643,4 @@ GET /my-index-000001/_search?scroll=1m
--------------------------------------------------
// TEST[setup:my_index_big]

For append only time-based indices, the `timestamp` field can be used safely.
For append only time-based indices, the `timestamp` field can be used safely.