Matches documents whose geo_point field lies inside an arbitrary
polygon. The ring is given as points in (lat, lon) order; vertices
on the boundary count as inside, and holes can be modelled with a
concave ring.
Real regions are rarely rectangular. City limits, districts, service areas and lakes have corners everywhere — this query filters points by an exact ring instead of the four edges of a bounding box.
...Returns documents whose key is in the provided set. There is no field argument — the match is against the document identity itself, and values that do not exist in the collection are skipped.
The query’s native name is keys: it speaks Pizza’s _key vocabulary,
the same word the REST API uses for by-key addressing. The ids
spelling deserializes to the same query — an accepted alias, not a
different feature.
Returns documents that match a provided text across several fields —
like the
match query, with per-field boosts and
multi-field scoring strategies.
Inside a
nestedquery: supported — fields under the nested path are matched per array element.
multi_match is expanded before execution (Query::simplify) into a
tree the segment executors already know:
fields — after splitting off a ^boost suffix —
becomes one
match query over that field, carrying the
query-level boost multiplied by the field boost ("title^3" →
per-field boost 3).type: "phrase" and type: "phrase_prefix" each field instead
becomes a
phrase query with slop: 0. The prefix part
is not implemented: phrase_prefix currently behaves as an exact
phrase and does not expand its last term as a prefix.bool whose should clauses
are the per-field queries, with at least one field required; a
single field collapses to that field’s query — a plain match.Scores: should clauses add their per-document scores (the bool
default). The type additionally picks the combination used when one
field name resolves to several indexed sub-fields — best_fields
keeps the maximum, most_fields and cross_fields sum. cross_fields
does not blend term statistics across fields; each
field scores independently and the results merge.
Returns documents that contain a specific prefix in a provided field.
Use it when the values share a known beginning — a hostname family, an ID scheme, a URL section — and you want every term that starts with it.
Inside a
nestedquery: not supported yet — the clause is rejected with an HTTP 400 naming the offending clause.
The prefix is expanded against the inverted index’s term dictionary.
Because the dictionary is kept in sorted order, the expansion is an
ordered seek to the first term greater than or equal to the prefix,
followed by reading the subtree of terms that start with it — no scan of
the whole dictionary. Each expanded term’s postings are then unioned
(OR semantics), exactly as if you had written a should of
term queries.
Term and full-text queries match document content; none of them can
ask “what is connected to these documents?” — the question citation
graphs, reference data and knowledge graphs are made of. The traverse
query answers it: a bounded graph traversal over a relation-typed
edge field — starting from seed documents, walk the edges up to
max_depth hops and emit every reached node as a hit.
Scores encode distance — 1.0 / (1.0 + depth) — so seeds outrank
1-hop neighbors, which outrank 2-hop neighbors, and the standard top-K
collector orders the results.
Returns documents that contain terms similar to the search term, within the maximum edit distance (Levenshtein — with transpositions counting as a single edit by default).
Use it when the indexed terms are only approximately known: typos in identifiers, OCR noise, or human-entered names.
Inside a
nestedquery: not supported yet — the clause is rejected with an HTTP 400 naming the offending clause.
The value is expanded against the inverted index’s term dictionary
by edit distance, then the survivors’ postings are unioned like a
should of
term queries. The engine takes the union of
three resolution passes — the value recorded as an exact term, a
whole-value fuzzy walk, and (on non-keyword fields) a per-token walk
after running the field’s search analyzer over the value — so the query
works on keyword fields and on analyzed text alike (the per-token pass
matters for CJK and multi-word input). On keyword fields the raw
value is used, with the field’s normalizer applied first and no
tokenization.
Matches documents whose geo_shape field relates to a query geometry by
a spatial relation. The query geometry is a GeoJSON geometry object or a
WKT string; the indexed shape was written the same way.
Where the geo_point queries ask “is this point inside my region?”,
geo_shape asks it of whole geometries — the document carries a
polygon, line or envelope (a delivery zone, a pipeline route, a parcel)
and the query tests it against another geometry.
Returns documents that match a compact query-syntax string, e.g.
status:active AND title:search. The same parser powers the
URI search parameter ?q=.
Inside a
nestedquery: not supported yet — the clause is rejected with an HTTP 400 naming the offending clause.
The query string is parsed with the classic query-string grammar and converted
to native queries: bare and field-qualified terms become analyzed
match queries, quoted phrases become
phrase queries,
and the boolean operators become
bool clauses. Terms
without a field: prefix go to default_field (or, when fields is
set, the query fans out into a bool.should across those fields with
their field^boost weights). The operator subset:
A query that matches documents matching boolean combinations of other queries. It is built using one or more boolean clauses.
Inside a
nestedquery: supported —must/filter/should/must_notandminimum_should_matchall apply within ONE array element; clauses matched by different elements never combine.
bool compiles each clause list into iterator algebra: must clauses
intersect (AND), must_not clauses subtract, filter clauses intersect
without scoring, and should clauses are probed per matched document —
a streaming two-pointer walk that adds each matching should score on
top of the base hit, with no intermediate materialization.
Returns documents that contain terms matching a wildcard pattern. The
pattern supports * (any sequence of characters, including none) and
? (any single character).
Inside a
nestedquery: not supported yet — the clause is rejected with an HTTP 400 naming the offending clause.
The pattern is expanded against the inverted index’s term dictionary:
the engine walks the field’s terms, keeps those matching the pattern, and
unions their postings lists — the same result as a should of
term queries over the surviving terms. Matching is anchored
at both ends: web-1 is the whole term, so web-* matches web-10 and
web-1 itself, but *web-1* is required for anything with text on both
sides.