From 768beea6c7d904e12ba91cb2abfb5cf2cc5cea05 Mon Sep 17 00:00:00 2001 From: Christoph Wurm Date: Tue, 5 Jul 2016 13:49:25 +0200 Subject: [PATCH] Update refresh.asciidoc Fix grammar and example --- docs/reference/docs/refresh.asciidoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/reference/docs/refresh.asciidoc b/docs/reference/docs/refresh.asciidoc index dd829e19bc3..6bf6d0885bc 100644 --- a/docs/reference/docs/refresh.asciidoc +++ b/docs/reference/docs/refresh.asciidoc @@ -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 <>. The <> 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