Browse Source

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.
Adrien Grand 10 years ago
parent
commit
35c0b50879

+ 4 - 2
docs/reference/mapping/params/doc-values.asciidoc

@@ -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

+ 3 - 2
docs/reference/mapping/types/binary.asciidoc

@@ -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`>>::
 

+ 3 - 2
docs/reference/mapping/types/boolean.asciidoc

@@ -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`>>::
 

+ 3 - 2
docs/reference/mapping/types/date.asciidoc

@@ -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`>>::
 

+ 3 - 2
docs/reference/mapping/types/geo-point.asciidoc

@@ -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`>>::
 

+ 3 - 2
docs/reference/mapping/types/ip.asciidoc

@@ -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`>>::
 

+ 3 - 2
docs/reference/mapping/types/numeric.asciidoc

@@ -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`>>::
 

+ 4 - 3
docs/reference/mapping/types/string.asciidoc

@@ -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`>>::
 

+ 3 - 2
docs/reference/mapping/types/token-count.asciidoc

@@ -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`>>::