[[index-boost]]
=== `boost`

Individual fields can be _boosted_ -- count more towards the relevance score
-- at index time, with the `boost` parameter as follows:

[source,js]
--------------------------------------------------
PUT my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "title": {
          "type": "string",
          "boost": 2 <1>
        },
        "content": {
          "type": "string"
        }
      }
    }
  }
}
--------------------------------------------------
// AUTOSENSE

<1> Matches on the `title` field will have twice the weight as those on the
    `content` field, which has the default `boost` of `1.0`.

Note that a `title` field will usually be shorter than a `content` field.  The
default relevance calculation takes field length into account, so a short
`title` field will have a higher natural boost than a long `content` field.

[WARNING]
.Why index time boosting is a bad idea
==================================================

We advise against using index time boosting for the following reasons:

* You cannot change index-time `boost` values without reindexing all of your
  documents.

* Every query supports query-time boosting which achieves the same effect. The
  difference is that you can tweak the `boost` value without having to reindex.

* Index-time boosts are stored as part of the <<norms,`norm`>>, which is only one
  byte.  This reduces the resolution of the field length normalization factor
  which can lead to lower quality relevance calculations.

==================================================

The only advantage that index time boosting has is that it is copied with the
value into the <<mapping-all-field,`_all`>> field. This means that, when
querying the `_all` field, words that originated from the `title` field will
have a higher score than words that originated in the `content` field.
This functionality comes at a cost: queries on the `_all` field are slower
when index-time boosting is used.