How does Elasticsearch's join field work with has_child and has_parent queries?

## Declaring the relation ```json { "mappings": { "properties": { "doc_relation": { "type": "join", "relations": { "question": "answer" } } }}} ``` One field, a map of parent name to child name (or to an array of child names when a parent has several kinds of child). An index may declare **one** join field only, and a child may have exactly one parent. Multi-level hierarchies are possible — a grandparent relation by chaining names — but each level compounds the cost and the documentation discourages it. ## Indexing A parent sets the field to its relation name; a child sets a name plus its parent's id, and the request must carry a `routing` parameter equal to that parent id: ``` PUT qa/_doc/1 { "text": "...", "doc_relation": "question" } PUT qa/_doc/2?routing=1 { "text": "...", "doc_relation": { "name": "answer", "parent": "1" } } ``` Routing is not optional and not a performance hint: the whole design rests on parent and children living on the same shard, so the join can be resolved locally with no cross-shard traffic. Get, update and delete requests for a child also need the same `routing`, and forgetting it is the classic "document not found on a document I just indexed" bug. A consequence of routing by parent id is skew: a parent with a million children puts all of them on one shard. Parent-child models with wildly uneven fan-out produce hot, oversized shards no matter how many shards the index has. ## Querying **`has_child`** — give it the child `type` and a `query`; it returns the **parents** whose children match. Options: `score_mode` (`none` by default, plus `avg`, `max`, `min`, `sum`) to roll child scores into the parent score, `min_children` and `max_children` to require a count range, and `inner_hits` to return the matching children alongside each parent. **`has_parent`** — give it the `parent_type` and a `query`; it returns the **children** whose parent matches. Its `score` parameter (a boolean, false by default) decides whether the parent's score propagates to the child. **`parent_id`** — given a relation `type` and a parent `id`, returns that parent's children directly. It is the cheap option when the parent is already known and no predicate on the parent is needed. Both joining queries work in filter context, and both are classed among Elasticsearch's expensive queries, so a cluster with `search.allow_expensive_queries` disabled will reject them. ## What it costs The join field is backed by **global ordinals** — a per-shard mapping of the field's values that lets the join be resolved quickly. For join fields these are built eagerly, which means the work happens at refresh time rather than at query time: refreshes on an index with a large join field get measurably more expensive, and a heavy indexing rate with a short refresh interval compounds that. Query time is worse than nested too, because the parent and child sets have to be looked up and intersected rather than walked as one contiguous block. In exchange you get true document independence: a child can be indexed, updated and deleted on its own, with no rewrite of the parent or of the other children. That is the one thing nested cannot do, and it is the only reason to accept the rest. ## When it earns its keep Parent-join fits when children vastly outnumber parents, when children change far more often than parents, and when the read pattern tolerates slower joining queries — a question with thousands of answers that arrive continuously, a product with a stream of price updates. It does not fit when the relation is small and static (nested is cheaper and faster), when search latency is critical at high query rates (denormalize), or when the parent and child would naturally live in different indices, since a join field cannot span indices. ## The practical guidance Elasticsearch's own advice is to prefer denormalization: copy the parent's fields onto the child documents and search the children directly, resolving the parent-level view with an aggregation on a parent id or a second query. That removes the join entirely, keeps every document independent, and scales with shard count instead of fighting it. Reach for `join` only when the update pattern genuinely forbids rewriting parents and the query volume is low enough to absorb the cost.