mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-08 22:14:59 +00:00
[Docs]Corrected spelling errors. (#28976)
This commit is contained in:
parent
80532229a9
commit
3530a676e0
@ -46,7 +46,7 @@ compared to `true`. In the case that the index is only changed once every
|
|||||||
`index.refresh_interval` then it saves no work.
|
`index.refresh_interval` then it saves no work.
|
||||||
* `true` creates less efficient indexes constructs (tiny segments) that must
|
* `true` creates less efficient indexes constructs (tiny segments) that must
|
||||||
later be merged into more efficient index constructs (larger segments). Meaning
|
later be merged into more efficient index constructs (larger segments). Meaning
|
||||||
that the cost of `true` is payed at index time to create the tiny segment, at
|
that the cost of `true` is paid at index time to create the tiny segment, at
|
||||||
search time to search the tiny segment, and at merge time to make the larger
|
search time to search the tiny segment, and at merge time to make the larger
|
||||||
segments.
|
segments.
|
||||||
* Never start multiple `refresh=wait_for` requests in a row. Instead batch them
|
* Never start multiple `refresh=wait_for` requests in a row. Instead batch them
|
||||||
|
@ -31,7 +31,7 @@ and <<search-request-highlighting,highlighting>> also become more expensive
|
|||||||
since their cost directly depends on the size of the original document.
|
since their cost directly depends on the size of the original document.
|
||||||
|
|
||||||
It is sometimes useful to reconsider what the unit of information should be.
|
It is sometimes useful to reconsider what the unit of information should be.
|
||||||
For instance, the fact you want to make books searchable doesn't necesarily
|
For instance, the fact you want to make books searchable doesn't necessarily
|
||||||
mean that a document should consist of a whole book. It might be a better idea
|
mean that a document should consist of a whole book. It might be a better idea
|
||||||
to use chapters or even paragraphs as documents, and then have a property in
|
to use chapters or even paragraphs as documents, and then have a property in
|
||||||
these documents that identifies which book they belong to. This does not only
|
these documents that identifies which book they belong to. This does not only
|
||||||
|
@ -65,7 +65,7 @@ documents and scores will be consistent.
|
|||||||
|
|
||||||
Otherwise the recommended way to work around this issue is to use the
|
Otherwise the recommended way to work around this issue is to use the
|
||||||
<<dfs-query-then-fetch,`dfs_query_then_fetch`>> search type. This will make
|
<<dfs-query-then-fetch,`dfs_query_then_fetch`>> search type. This will make
|
||||||
Elasticsearch perform an inital round trip to all involved shards, asking
|
Elasticsearch perform an initial round trip to all involved shards, asking
|
||||||
them for their index statistics relatively to the query, then the coordinating
|
them for their index statistics relatively to the query, then the coordinating
|
||||||
node will merge those statistics and send the merged statistics alongside the
|
node will merge those statistics and send the merged statistics alongside the
|
||||||
request when asking shards to perform the `query` phase, so that shards can
|
request when asking shards to perform the `query` phase, so that shards can
|
||||||
|
@ -3,7 +3,7 @@
|
|||||||
|
|
||||||
Removes matches which overlap with another span query or which are
|
Removes matches which overlap with another span query or which are
|
||||||
within x tokens before (controlled by the parameter `pre`) or y tokens
|
within x tokens before (controlled by the parameter `pre`) or y tokens
|
||||||
after (controled by the parameter `post`) another SpanQuery. The span not
|
after (controlled by the parameter `post`) another SpanQuery. The span not
|
||||||
query maps to Lucene `SpanNotQuery`. Here is an example:
|
query maps to Lucene `SpanNotQuery`. Here is an example:
|
||||||
|
|
||||||
[source,js]
|
[source,js]
|
||||||
|
Loading…
x
Reference in New Issue
Block a user