[[number]] === Numeric datatypes The following numeric types are supported: [horizontal] `long`:: A signed 64-bit integer with a minimum value of +-2^63^+ and a maximum value of +2^63^-1+. `integer`:: A signed 32-bit integer with a minimum value of +-2^31^+ and a maximum value of +2^31^-1+. `short`:: A signed 16-bit integer with a minimum value of +-32,768+ and a maximum value of +32,767+. `byte`:: A signed 8-bit integer with a minimum value of +-128+ and a maximum value of +127+. `double`:: A double-precision 64-bit IEEE 754 floating point. `float`:: A single-precision 32-bit IEEE 754 floating point. `half_float`:: A half-precision 16-bit IEEE 754 floating point. Below is an example of configuring a mapping with numeric fields: [source,js] -------------------------------------------------- PUT my_index { "mappings": { "my_type": { "properties": { "number_of_bytes": { "type": "integer" }, "time_in_seconds": { "type": "float" } } } } } -------------------------------------------------- // CONSOLE ==== Which type should I use? As far as integer types (`byte`, `short`, `integer` and `long`) are concerned, you should pick the smallest type which is enough for your use-case. This will help indexing and searching be more efficient. Note however that given that storage is optimized based on the actual values that are stored, picking one type over another one will have no impact on storage requirements. For floating-point types, picking the smallest type that is enough for the use-case will still help indexing and searching be more efficient. However, given that floating-point data is hard to compress, it might also have a significant impact on storage requirements. Here is a table that compares the 3 floating-point types that are available in order to help make a decision. [cols="<,<,<,<",options="header",] |======================================================================= |Type |Minimum value |Maximum value |Significant bits / digits |`double`|+2^-1074^+ |+(2-2^-52^)·2^1023^+ |+53+ / +15.95+ |`float`|+2^-149^+ |+(2-2^-23^)·2^127^+ |+24+ / +7.22+ |`half_float`|+2^-24^+ |+65504+ |+11+ / +3.31+ |======================================================================= When possible, it is often more efficient to store floating-point data into an integer using a scaling factor. For instance, it is more efficient to store percentages as integers between 0 and 100 than as floating-point numbers between 0 and 1. Another example would be prices: it will be more efficient to store prices as a number of cents, which is an integer, than as a floating-point number. [[number-params]] ==== Parameters for numeric fields The following parameters are accepted by numeric types: [horizontal] <>:: Try to convert strings to numbers and truncate fractions for integers. Accepts `true` (default) and `false`. <>:: Mapping field-level query time boosting. Accepts a floating point number, defaults to `1.0`. <>:: 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`. <>:: If `true`, malformed numbers are ignored. If `false` (default), malformed numbers throw an exception and reject the whole document. <>:: Whether or not the field value should be included in the <> field? Accepts `true` or `false`. Defaults to `false` if <> is set to `false`, or if a parent <> field sets `include_in_all` to `false`. Otherwise defaults to `true`. <>:: Should the field be searchable? Accepts `true` (default) and `false`. <>:: Accepts a numeric value of the same `type` as the field which is substituted for any explicit `null` values. Defaults to `null`, which means the field is treated as missing. <>:: Whether the field value should be stored and retrievable separately from the <> field. Accepts `true` or `false` (default).