WARNING: The 2.x versions of Elasticsearch have passed their EOL dates. If you are running a 2.x version, we strongly advise you to upgrade.
This documentation is no longer maintained and may be removed. For the latest information, see the current Elasticsearch documentation.
Phrase and proximity queries are more expensive than simple
match query just has to look up terms in the inverted index, a
match_phrase query has to calculate and compare the positions of multiple
possibly repeated terms.
The Lucene nightly
benchmarks show that a simple
term query is about 10 times as fast as a
phrase query, and about 20 times as fast as a proximity query (a phrase query
slop). And of course, this cost is paid at search time instead of at index time.
Usually the extra cost of phrase queries is not as scary as these numbers
suggest. Really, the difference in performance is a testimony to just how fast
term query is. Phrase queries on typical full-text data usually
complete within a few milliseconds, and are perfectly usable in practice, even
on a busy cluster.
In certain pathological cases, phrase queries can be costly, but this is
unusual. An example of a pathological case is DNA sequencing, where there are
many many identical terms repeated in many positions. Using higher
values in this case results in a huge growth in the number of position
So what can we do to limit the performance cost of phrase and proximity queries? One useful approach is to reduce the total number of documents that need to be examined by the phrase query.
In the preceding section, we discussed using proximity queries just for relevance purposes, not to include or exclude results from the result set. A query may match millions of results, but chances are that our users are interested in only the first few pages of results.
match query will already have ranked documents that contain all
search terms near the top of the list. Really, we just want to rerank the top
results to give an extra relevance bump to those documents that also match the
search API supports exactly this functionality via rescoring. The
rescore phase allows you to apply a more expensive scoring algorithm—like a
phrase query—to just the top
K results from each shard. These top
results are then resorted according to their new scores.
The request looks like this:
The only rescoring algorithm currently supported is another query, but there are plans to add more algorithms later.