Reword some documentation to make it more obvious that doc values are a columnar representation of the data.
Some users may already be familiar with column stores, so saying more explicitly that doc values are a columnar representation of the data may help them better and/or more quickly understand what doc values are about.
This commit is contained in:
parent
d0853e9253
commit
35c0b50879
|
@ -12,8 +12,10 @@ documents, we need to be able to look up the document and find the terms that
|
|||
is has in a field.
|
||||
|
||||
Doc values are the on-disk data structure, built at document index time, which
|
||||
makes this data access pattern possible. Doc values are supported on almost
|
||||
all field types, with the __notable exception of `analyzed` string fields__.
|
||||
makes this data access pattern possible. They store the same values as the
|
||||
`_source` but in a column-oriented fashion that is way more efficient for
|
||||
sorting and aggregations. Doc values are supported on almost all field types,
|
||||
with the __notable exception of `analyzed` string fields__.
|
||||
|
||||
All fields which support doc values have them enabled by default. If you are
|
||||
sure that you don't need to sort or aggregate on a field, or access the field
|
||||
|
|
|
@ -40,8 +40,9 @@ The following parameters are accepted by `binary` fields:
|
|||
|
||||
<<doc-values,`doc_values`>>::
|
||||
|
||||
Can the field value be used for sorting, aggregations, or scripting?
|
||||
Accepts `true` or `false` (default).
|
||||
Should the field be stored on disk in a column-stride fashion, so that it
|
||||
can later be used for sorting, aggregations, or scripting? Accepts `true`
|
||||
(default) or `false`.
|
||||
|
||||
<<mapping-store,`store`>>::
|
||||
|
||||
|
|
|
@ -98,8 +98,9 @@ The following parameters are accepted by `boolean` fields:
|
|||
|
||||
<<doc-values,`doc_values`>>::
|
||||
|
||||
Can the field value be used for sorting, aggregations, or scripting?
|
||||
Accepts `true` (default) or `false`.
|
||||
Should the field be stored on disk in a column-stride fashion, so that it
|
||||
can later be used for sorting, aggregations, or scripting? Accepts `true`
|
||||
(default) or `false`.
|
||||
|
||||
<<mapping-index,`index`>>::
|
||||
|
||||
|
|
|
@ -97,8 +97,9 @@ The following parameters are accepted by `date` fields:
|
|||
|
||||
<<doc-values,`doc_values`>>::
|
||||
|
||||
Can the field value be used for sorting, aggregations, or scripting?
|
||||
Accepts `true` (default) or `false`.
|
||||
Should the field be stored on disk in a column-stride fashion, so that it
|
||||
can later be used for sorting, aggregations, or scripting? Accepts `true`
|
||||
(default) or `false`.
|
||||
|
||||
<<mapping-date-format,`format`>>::
|
||||
|
||||
|
|
|
@ -108,8 +108,9 @@ The following parameters are accepted by `geo_point` fields:
|
|||
|
||||
<<doc-values,`doc_values`>>::
|
||||
|
||||
Can the field value be used for sorting, aggregations, or scripting?
|
||||
Accepts `true` (default) or `false`.
|
||||
Should the field be stored on disk in a column-stride fashion, so that it
|
||||
can later be used for sorting, aggregations, or scripting? Accepts `true`
|
||||
(default) or `false`.
|
||||
|
||||
<<geohash,`geohash`>>::
|
||||
|
||||
|
|
|
@ -54,8 +54,9 @@ The following parameters are accepted by `ip` fields:
|
|||
|
||||
<<doc-values,`doc_values`>>::
|
||||
|
||||
Can the field value be used for sorting, aggregations, or scripting?
|
||||
Accepts `true` (default) or `false`.
|
||||
Should the field be stored on disk in a column-stride fashion, so that it
|
||||
can later be used for sorting, aggregations, or scripting? Accepts `true`
|
||||
(default) or `false`.
|
||||
|
||||
<<include-in-all,`include_in_all`>>::
|
||||
|
||||
|
|
|
@ -52,8 +52,9 @@ The following parameters are accepted by numeric types:
|
|||
|
||||
<<doc-values,`doc_values`>>::
|
||||
|
||||
Can the field value be used for sorting, aggregations, or scripting?
|
||||
Accepts `true` (default) or `false`.
|
||||
Should the field be stored on disk in a column-stride fashion, so that it
|
||||
can later be used for sorting, aggregations, or scripting? Accepts `true`
|
||||
(default) or `false`.
|
||||
|
||||
<<ignore-malformed,`ignore_malformed`>>::
|
||||
|
||||
|
|
|
@ -82,9 +82,10 @@ The following parameters are accepted by `string` fields:
|
|||
|
||||
<<doc-values,`doc_values`>>::
|
||||
|
||||
Can the field use on-disk index-time doc values for sorting, aggregations,
|
||||
or scripting? Accepts `true` or `false`. Defaults to `true` for
|
||||
`not_analyzed` fields. Analyzed fields do not support doc values.
|
||||
Should the field be stored on disk in a column-stride fashion, so that it
|
||||
can later be used for sorting, aggregations, or scripting? Accepts `true`
|
||||
or `false`. Defaults to `true` for `not_analyzed` fields. Analyzed fields
|
||||
do not support doc values.
|
||||
|
||||
<<fielddata,`fielddata`>>::
|
||||
|
||||
|
|
|
@ -75,8 +75,9 @@ The following parameters are accepted by `token_count` fields:
|
|||
|
||||
<<doc-values,`doc_values`>>::
|
||||
|
||||
Can the field value be used for sorting, aggregations, or scripting?
|
||||
Accepts `true` (default) or `false`.
|
||||
Should the field be stored on disk in a column-stride fashion, so that it
|
||||
can later be used for sorting, aggregations, or scripting? Accepts `true`
|
||||
(default) or `false`.
|
||||
|
||||
<<mapping-index,`index`>>::
|
||||
|
||||
|
|
Loading…
Reference in New Issue