[DOCS] terminate_after is not experimental anymore

we are relying on terminate_after more and more, replaced the limit filter with it and soon it will also replace the search_exists api. At that point we should make it a stable api rather than experimental.

Closes #14183
This commit is contained in:
javanna 2015-10-19 09:48:54 +02:00 committed by Luca Cavanna
parent 7dd35c5a12
commit c5152c7ecb
3 changed files with 2 additions and 5 deletions

View File

@ -73,8 +73,7 @@ not. Defaults to `true`.
|`analyze_wildcard` |Should wildcard and prefix queries be analyzed or
not. Defaults to `false`.
|`terminate_after` |experimental[The API for this feature may change in the future]
The maximum count for each shard, upon
|`terminate_after` |The maximum count for each shard, upon
reaching which the query execution will terminate early.
If set, the response will have a boolean field `terminated_early` to
indicate whether the query execution has actually terminated_early.

View File

@ -79,7 +79,6 @@ And here is a sample response:
`terminate_after`::
experimental[The API for this feature may change in the future]
The maximum number of documents to collect for each shard,
upon reaching which the query execution will terminate early. If set, the
response will have a boolean field `terminated_early` to indicate whether

View File

@ -91,8 +91,7 @@ scores and return them as part of each hit.
within the specified time value and bail with the hits accumulated up to
that point when expired. Defaults to no timeout.
|`terminate_after` |experimental[The API for this feature may change in the future]
The maximum number of documents to collect for
|`terminate_after` |The maximum number of documents to collect for
each shard, upon reaching which the query execution will terminate early.
If set, the response will have a boolean field `terminated_early` to
indicate whether the query execution has actually terminated_early.