What does inner_hits add to an Elasticsearch nested query's results?

## The problem it solves A `nested` query answers a parent-level question — "which products have a variant in red, size M, in stock?" — and returns products. The hit's `_source` is the whole product document, all fifty variants included. The UI, however, usually needs to show the *matching* variant: its price, its SKU, its image. Nothing in an ordinary response tells you which of the fifty caused the match, and re-evaluating the predicate in application code duplicates the query logic and gets it wrong the moment analysis is involved. `inner_hits` closes that gap. Adding it to the `nested` query makes Elasticsearch run a small secondary retrieval, per returned hit, over that hit's inner documents, and return them inline. ## The response shape Each top-level hit gains an `inner_hits` object keyed by the nested path (or by the `name` you supply), containing a miniature search response: `total`, and a `hits` array whose entries have `_source` (the inner object as it appeared in the original JSON), `_score`, and a `_nested` block naming the `field` and the zero-based `offset` of that object within the array. The offset is what lets a client line the inner hit up with the element it came from, which matters when two variants share the same field values. ## Options worth knowing - `size` — how many inner documents to return per hit. Only the top few come back by default (3), which quietly truncates results when a document has many matching children; raise it deliberately, and remember every extra inner hit is more work and more payload. - `from` — offset within the inner hits, for paging inside a single parent. - `sort` — order the inner hits by a child field rather than by relevance; a variant list is usually more useful sorted by price than by score. - `_source` — include or exclude child fields, keeping payloads small when children are fat. - `highlight` — highlight on the child fields, which is the only way to get a snippet from the matched child rather than from the whole parent. - `name` — required in practice when a query has more than one `inner_hits` block (two nested queries, or a nested plus a child query); without distinct names the responses collide. ## Beyond nested `inner_hits` is not nested-specific. On a `has_child` query it returns the matching child documents alongside each parent hit; on a `has_parent` query it returns the matched parent alongside each child hit. That is often the only reason a parent-child model is bearable in a UI — otherwise a second round trip is needed just to fetch the related documents. ## Cost Inner hits are retrieved during the fetch phase, after the main query has selected the top documents. That bounds the work by page size rather than by the whole result set, but it is still real: for each returned hit, Elasticsearch runs the inner query against that document's children and materialises their source. A page of 50 hits with `size: 20` inner hits materialises up to a thousand child sources. Highlighting inner hits multiplies it again. If a client only needs a count of matching children rather than their content, it is cheaper to omit `inner_hits` and use a `nested` aggregation, or to accept the parent-level answer. ## Practical notes - The scores you see on inner hits are the child scores that `score_mode` rolled up into the parent's `_score`; they are useful for debugging why a parent scored the way it did. - Inner hits reflect the inner query, not the whole search. A filter applied outside the `nested` query does not restrict which children come back. - Because the inner `_source` is reconstructed from the parent's stored `_source`, disabling `_source` on the index removes inner hit content too.