Has Child Filter

The has_child filter accepts a query and the child type to run against, and results in parent documents that have child docs matching the query. Here is an example:

{
    "has_child" : {
        "type" : "blog_tag",
        "query" : {
            "term" : {
                "tag" : "something"
            }
        }
    }
}

The type is the child type to query against. The parent type to return is automatically detected based on the mappings.

The way that the filter is implemented is by first running the child query, doing the matching up to the parent doc for each document matched.

The has_child filter also accepts a filter instead of a query:

{
    "has_child" : {
        "type" : "comment",
        "filter" : {
            "term" : {
                "user" : "john"
            }
        }
    }
}

The has_child filter allows you to specify that a minimum and/or maximum number of children are required to match for the parent doc to be considered a match:

{
    "has_child" : {
        "type" : "comment",
        "min_children": 2, 
        "max_children": 10, 
        "filter" : {
            "term" : {
                "user" : "john"
            }
        }
    }
}

The execution speed of the has_child filter is equivalent to that of the has_child query when min_children or max_children is specified.

In order to support parent-child joins, all of the (string) parent IDs must be resident in memory (in the field data cache. Additionally, every child document is mapped to its parent using a long value (approximately). It is advisable to keep the string parent ID short in order to reduce memory usage.

You can check how much memory is being used by the ID cache using the indices stats or nodes stats APIS, eg:

curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"

The has_child filter cannot be cached in the filter cache. The _cache and _cache_key options are a no-op in this filter. Also any filter that wraps the has_child filter either directly or indirectly will not be cached.