[DOCS] Add soft redirect for sliced scroll (#60699) (#60733)

This commit is contained in:
James Rodewig 2020-08-05 09:23:15 -04:00 committed by GitHub
parent 160f27f77c
commit e2553d5884
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 22 additions and 7 deletions

View File

@ -130,7 +130,7 @@ This is "bursty" instead of "smooth".
[[docs-delete-by-query-slice]]
===== Slicing
Delete by query supports <<sliced-scroll, sliced scroll>> to parallelize the
Delete by query supports <<slice-scroll, sliced scroll>> to parallelize the
delete process. This can improve efficiency and provide a
convenient way to break the request down into smaller parts.
@ -487,7 +487,7 @@ Which results in a sensible `total` like this one:
===== Use automatic slicing
You can also let delete-by-query automatically parallelize using
<<sliced-scroll, sliced scroll>> to slice on `_id`. Use `slices` to specify
<<slice-scroll, sliced scroll>> to slice on `_id`. Use `slices` to specify
the number of slices to use:
[source,console]

View File

@ -187,7 +187,7 @@ timeouts.
[[docs-reindex-slice]]
===== Slicing
Reindex supports <<sliced-scroll>> to parallelize the reindexing process.
Reindex supports <<slice-scroll>> to parallelize the reindexing process.
This parallelization can improve efficiency and provide a convenient way to
break the request down into smaller parts.
@ -257,7 +257,7 @@ which results in a sensible `total` like this one:
[[docs-reindex-automatic-slice]]
====== Automatic slicing
You can also let `_reindex` automatically parallelize using <<sliced-scroll>> to
You can also let `_reindex` automatically parallelize using <<slice-scroll>> to
slice on `_id`. Use `slices` to specify the number of slices to use:
[source,console]

View File

@ -125,7 +125,7 @@ This is "bursty" instead of "smooth".
[[docs-update-by-query-slice]]
===== Slicing
Update by query supports <<sliced-scroll, sliced scroll>> to parallelize the
Update by query supports <<slice-scroll, sliced scroll>> to parallelize the
update process. This can improve efficiency and provide a
convenient way to break the request down into smaller parts.
@ -600,7 +600,7 @@ Which results in a sensible `total` like this one:
===== Use automatic slicing
You can also let update by query automatically parallelize using
<<sliced-scroll>> to slice on `_id`. Use `slices` to specify the number of
<<slice-scroll>> to slice on `_id`. Use `slices` to specify the number of
slices to use:
[source,console]

View File

@ -999,6 +999,16 @@ See <<how-es-highlighters-work-internally>>.
See <<scroll-search-results>>.
[[_clear_scroll_api]]
===== Clear scroll API
See <<clear-scroll-api>>.
[[sliced-scroll]]
===== Sliced scroll
See <<slice-scroll>>.
[role="exclude",id="request-body-search-search-after"]
==== Search After

View File

@ -149,6 +149,11 @@ See <<scroll-search-results>>.
See <<clear-scroll-api>>.
[[sliced-scroll]]
===== Sliced scroll
See <<slice-scroll>>.
[[request-body-search-search-after]]
==== Search After

View File

@ -201,7 +201,7 @@ DELETE /_search/scroll/DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMN
// TEST[catch:missing]
[discrete]
[[sliced-scroll]]
[[slice-scroll]]
==== Sliced Scroll
For scroll queries that return a lot of documents it is possible to split the scroll in multiple slices which