1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
[[query-dsl-has-child-filter]]
=== 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:
[source,js]
--------------------------------------------------
{
"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:
[source,js]
--------------------------------------------------
{
"has_child" : {
"type" : "comment",
"filter" : {
"term" : {
"user" : "john"
}
}
}
}
--------------------------------------------------
[float]
==== Min/Max Children
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:
[source,js]
--------------------------------------------------
{
"has_child" : {
"type" : "comment",
"min_children": 2, <1>
"max_children": 10, <1>
"filter" : {
"term" : {
"user" : "john"
}
}
}
}
--------------------------------------------------
<1> Both `min_children` and `max_children` are optional.
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.
[float]
==== Memory Considerations
In order to support parent-child joins, all of the (string) parent IDs
must be resident in memory (in the <<index-modules-fielddata,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,indices stats>> or <<cluster-nodes-stats,nodes stats>>
APIS, eg:
[source,js]
--------------------------------------------------
curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
--------------------------------------------------
[float]
==== Caching
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.
|
