Removed docs for precision_step - no longer used

This commit is contained in:
Clinton Gormley 2016-06-21 15:18:59 +02:00
parent ba1d6907ab
commit 0160d91c2c
4 changed files with 0 additions and 69 deletions

View File

@ -80,8 +80,6 @@ include::params/null-value.asciidoc[]
include::params/position-increment-gap.asciidoc[] include::params/position-increment-gap.asciidoc[]
include::params/precision-step.asciidoc[]
include::params/properties.asciidoc[] include::params/properties.asciidoc[]
include::params/search-analyzer.asciidoc[] include::params/search-analyzer.asciidoc[]

View File

@ -1,56 +0,0 @@
[[precision-step]]
=== `precision_step`
Most <<number,numeric>> datatypes index extra terms representing numeric
ranges for each number to make <<query-dsl-range-query,`range` queries>>
faster. For instance, this `range` query:
[source,js]
--------------------------------------------------
"range": {
"number": {
"gte": 0
"lte": 321
}
}
--------------------------------------------------
might be executed internally as a <<query-dsl-terms-query,`terms` query>> that
looks something like this:
[source,js]
--------------------------------------------------
"terms": {
"number": [
"0-255",
"256-319"
"320",
"321"
]
}
--------------------------------------------------
These extra terms greatly reduce the number of terms that have to be examined,
at the cost of increased disk space.
The default value for `precision_step` depends on the `type` of the numeric field:
[horizontal]
`long`, `double`, `date`, `ip`:: `16` (3 extra terms)
`integer`, `float`, `short`:: `8` (3 extra terms)
`byte`:: `2147483647` (0 extra terms)
`token_count`:: `32` (0 extra terms)
The value of the `precision_step` setting indicates the number of bits that
should be compressed into an extra term. A `long` value consists of 64 bits,
so a `precision_step` of 16 results in the following terms:
[horizontal]
Bits 0-15:: `value & 1111111111111111 0000000000000000 0000000000000000 0000000000000000`
Bits 0-31:: `value & 1111111111111111 1111111111111111 0000000000000000 0000000000000000`
Bits 0-47:: `value & 1111111111111111 1111111111111111 1111111111111111 0000000000000000`
Bits 0-63:: `value`

View File

@ -126,12 +126,6 @@ The following parameters are accepted by `geo_point` fields:
Should the geo-point also be indexed as `.lat` and `.lon` sub-fields? Should the geo-point also be indexed as `.lat` and `.lon` sub-fields?
Accepts `true` and `false` (default). Accepts `true` and `false` (default).
<<precision-step,`precision_step`>>::
Controls the number of extra terms that are indexed for each lat/lon point.
Defaults to `16`. Ignored if `lat_lon` is `false`.
==== Using geo-points in scripts ==== Using geo-points in scripts
When accessing the value of a geo-point in a script, the value is returned as When accessing the value of a geo-point in a script, the value is returned as

View File

@ -96,11 +96,6 @@ The following parameters are accepted by `token_count` fields:
substituted for any explicit `null` values. Defaults to `null`, which substituted for any explicit `null` values. Defaults to `null`, which
means the field is treated as missing. means the field is treated as missing.
<<precision-step,`precision_step`>>::
Controls the number of extra terms that are indexed to make
<<query-dsl-range-query,`range` queries>> faster. Defaults to `32`.
<<mapping-store,`store`>>:: <<mapping-store,`store`>>::
Whether the field value should be stored and retrievable separately from Whether the field value should be stored and retrievable separately from