Match all query

Match all query #

Matches every document. This is the default query used when no query is sent in a search request — relevance-free, constant-scored, and the base every “everything, then narrow” pattern builds on.

How it works #

match_all walks every document in the target indexes with a constant score — 1.0 — so _score carries no ranking information and downstream score arithmetic (indices_boost, bool should boosts, cross-engine merges) sees the same baseline everywhere. boost multiplies the constant, and is the only parameter there is.

Regexp query

Regexp query #

Returns documents that contain terms matching a regular expression.

A regular expression is a way to match patterns in data using placeholder characters, called operators. For a list of operators supported by the regexp query, see Regular expression syntax. Use the regexp query when neither prefix, suffix nor wildcard can express the shape — alternation, character classes, repetition.

Inside a nested query: not supported yet — the clause is rejected with an HTTP 400 naming the offending clause.

...

Span queries

Span queries #

Span queries are low-level positional queries that expose and control the positions of terms — the building blocks for phrase-adjacent logic that phrase does not express directly. Most use cases are better served by match_phrase (or its slop); the span family exists for the remaining ones.

Inside a nested query: not supported yet — span clauses are rejected with an HTTP 400 naming the offending clause. Use phrase with slop for positional logic.

...

Suffix query

Suffix query #

Returns documents that contain terms ending in the provided value. This is the mirror of the prefix query; like a leading wildcard, it is more expensive than a prefix match.

Inside a nested query: not supported yet — the clause is rejected with an HTTP 400 naming the offending clause.

How it works #

A term dictionary is sorted by its beginnings, so a prefix can seek directly to its subtree — but a suffix cannot. The engine therefore walks the whole dictionary of the field and keeps the terms that end with the value, then unions their postings lists exactly like a should of term queries. The cost is proportional to the number of distinct terms in the field, not to the number of matches, which is why the suffix query is marked more expensive than prefix.

Intervals query

Intervals query #

The intervals query is a rule language for term positions: it matches documents whose analyzed token stream satisfies proximity rules you express as a tree — fixed token sequences, maximum gaps, required order, unions, multi-term leaves, and positional filters between sibling rules. It covers everything phrase expresses plus the shapes a phrase cannot: unordered combinations with bounded width, disjunctions of positional rules, and prefix/wildcard/fuzzy/regexp leaves inside positional composition.

Range query

Range query #

Returns documents that contain terms within a provided range.

Use it for intervals: prices between two numbers, events inside a time window, names inside an alphabetical span — anything expressible as “from / to” bounds rather than a list of exact values.

Inside a nested query: supported — the bounds apply per array element.

How it works #

The engine picks the index by field type:

Exists query

Exists query #

Returns documents that contain an indexed value for a specific field.

A document matches when the field has at least one non-null value — an empty string or an empty array does not count as existing.

Inside a nested query: supported — matches elements that carry the field.

How it works #

exists never touches the inverted index. It is answered from the stored-field / column layer, where every document either carries the key or does not:

More like this query

More like this query #

more_like_this finds documents similar to given text or documents. The engine extracts the input’s terms, keeps the significant ones, and runs the resulting top terms as a disjunctive query — a “find more of this” query without any embedding model.

fields is required and limited to text fields.

How it works #

The query is rewritten at the search entry point — it is a client of the analysis and term pipeline, not an index structure. Per field: gather the like text (free text is analyzed with the first field’s analyzer; a referenced document contributes the text of every query field), tokenize it, drop terms below min_term_freq, outside the word-length bounds, or listed in stop_words, and remove every term the unlike inputs produced. The surviving terms from all fields are pooled, ranked by source term frequency (ties broken alphabetically for determinism), and the top max_query_terms become a bool.should of term queries governed by minimum_should_match. If nothing survives, the query matches nothing. When include is false (the default) and the like input named documents, their ids are added as a must_not — the seed documents trivially contain every selected term.