diff --git a/docs/reference/docs/delete-by-query.asciidoc b/docs/reference/docs/delete-by-query.asciidoc index 265a29a656e..3c5fad65788 100644 --- a/docs/reference/docs/delete-by-query.asciidoc +++ b/docs/reference/docs/delete-by-query.asciidoc @@ -341,8 +341,7 @@ take effect on after completing the current batch. This prevents scroll timeouts. [float] -=== Slicing - +[[docs-delete-by-query-manual-slice]] === Manually slicing Delete-by-query supports <> allowing you to manually parallelize @@ -413,7 +412,9 @@ Which results in a sensible `total` like this one: ---------------------------------------------------------------- // TESTRESPONSE -==== Automatic slicing +[float] +[[docs-delete-by-query-automatic-slice]] +=== Automatic slicing You can also let delete-by-query automatically parallelize using <> to slice on `_uid`: @@ -487,7 +488,9 @@ above about distribution being uneven and you should conclude that the using * Each sub-requests gets a slightly different snapshot of the source index though these are all taken at approximately the same time. -==== Picking the number of slices +[float] +[[docs-delete-by-query-picking-slices]] +=== Picking the number of slices At this point we have a few recommendations around the number of `slices` to use (the `max` parameter in the slice API if manually parallelizing): diff --git a/docs/reference/docs/reindex.asciidoc b/docs/reference/docs/reindex.asciidoc index 118c57ed89e..6279c3cae0f 100644 --- a/docs/reference/docs/reindex.asciidoc +++ b/docs/reference/docs/reindex.asciidoc @@ -737,8 +737,7 @@ and it'll look like: Or you can search by `tag` or whatever you want. [float] -=== Slicing - +[[docs-reindex-manual-slice]] ==== Manual slicing Reindex supports <>, allowing you to manually parallelize the process relatively easily: @@ -797,7 +796,9 @@ Which results in a sensible `total` like this one: ---------------------------------------------------------------- // TESTRESPONSE -==== Automatic slicing +[float] +[[docs-reindex-automatic-slice]] +=== Automatic slicing You can also let reindex automatically parallelize using <> to slice on `_uid`: @@ -860,7 +861,9 @@ above about distribution being uneven and you should conclude that the using * Each sub-requests gets a slightly different snapshot of the source index though these are all taken at approximately the same time. -==== Picking the number of slices +[float] +[[docs-reindex-picking-slices]] +=== Picking the number of slices At this point we have a few recommendations around the number of `slices` to use (the `max` parameter in the slice API if manually parallelizing): diff --git a/docs/reference/docs/update-by-query.asciidoc b/docs/reference/docs/update-by-query.asciidoc index 8731d5202bd..69c22921225 100644 --- a/docs/reference/docs/update-by-query.asciidoc +++ b/docs/reference/docs/update-by-query.asciidoc @@ -406,8 +406,7 @@ take effect on after completing the current batch. This prevents scroll timeouts. [float] -=== Slicing - +[[docs-update-by-query-manual-slice]] ==== Manual slicing Update-by-query supports <> allowing you to manually parallelize the process relatively easily: @@ -460,7 +459,9 @@ Which results in a sensible `total` like this one: ---------------------------------------------------------------- // TESTRESPONSE -==== Automatic slicing +[float] +[[docs-update-by-query-automatic-slice]] +=== Automatic slicing You can also let update-by-query automatically parallelize using <> to slice on `_uid`: @@ -521,7 +522,9 @@ above about distribution being uneven and you should conclude that the using * Each sub-requests gets a slightly different snapshot of the source index though these are all taken at approximately the same time. -==== Picking the number of slices +[float] +[[docs-update-by-query-picking-slices]] +=== Picking the number of slices At this point we have a few recommendations around the number of `slices` to use (the `max` parameter in the slice API if manually parallelizing):