parent
d1727653dd
commit
768beea6c7
|
@ -17,7 +17,7 @@ indexing and a search standpoint.
|
|||
|
||||
Wait for the changes made by the request to be made visible by a refresh before
|
||||
replying. This doesn't force an immediate refresh, rather, it waits for a
|
||||
refresh happen. Elasticsearch automatically refreshes shards that have changed
|
||||
refresh to happen. Elasticsearch automatically refreshes shards that have changed
|
||||
every `index.refresh_interval` which defaults to one second. That setting is
|
||||
<<dynamic-index-settings,dynamic>>. The <<indices-refresh>> API will also
|
||||
cause the request to return, as will setting `refresh` to `true` on any of the
|
||||
|
@ -36,7 +36,7 @@ use `refresh=false`, or, because that is the default, just leave the `refresh`
|
|||
parameter out of the URL. That is the simplest and fastest choice.
|
||||
|
||||
If you absolutely must have the changes made by a request visible synchronously
|
||||
with the request then you must get to pick between putting more load on
|
||||
with the request then you must pick between putting more load on
|
||||
Elasticsearch (`true`) and waiting longer for the response (`wait_for`). Here
|
||||
are a few points that should inform that decision:
|
||||
|
||||
|
@ -97,7 +97,7 @@ search:
|
|||
--------------------------------------------------
|
||||
PUT /test/test/3
|
||||
{"test": "test"}
|
||||
PUT /test/test/4?refresh=true
|
||||
PUT /test/test/4?refresh=false
|
||||
{"test": "test"}
|
||||
--------------------------------------------------
|
||||
// CONSOLE
|
||||
|
|
Loading…
Reference in New Issue