# Very slow has\_child query for large index **URL:** \ **Category:** Elasticsearch\ **Created:** [June 20, 2013, 12:05pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494 "2013-06-20T12:05:01Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![David\_MZ](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/david_mz/32/2215_2.png) [@David\_MZ](https://discuss.elastic.co/u/David_MZ)\ **Post date:** [June 20, 2013, 12:05pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/1 "2013-06-20T12:05:01Z")
I have a 40 million child documents with 20 million parents on 3 shards all hosted within one machine My specs are elastic 0.9, 8 cores, 8 gigs dedicated memory I am performing a has\_child query, and it doesn't seem to return even after 15 minutes Here is my query curl -XPOST "[http://xxxx/people/household/\_search?search\_type=count](http://xxxx/people/household/_search?search_type=count)" -d' { "query": { "has\_child": { "type": "person", "query" : { "filtered": { "query": { "match\_all": {}}, "filter" : { "bool": { "must": [ {"term": {"exact\_age": "65"}}, {"term": {"gender": "m"}} ] } } } } } } }' Is there something I am doing wrong, is there a way to check what is taking so long Thanks -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![David\_MZ](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/david_mz/32/2215_2.png) [@David\_MZ](https://discuss.elastic.co/u/David_MZ)\ **Post date:** [June 20, 2013, 12:53pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/2 "2013-06-20T12:53:20Z")
UPDATE: my query returned taking 30 minutes On Thursday, June 20, 2013 3:05:01 PM UTC+3, David MZ wrote: > I have a 40 million child documents with 20 million parents on 3 shards > all hosted within one machine > My specs are elastic 0.9, 8 cores, 8 gigs dedicated memory > > I am performing a has\_child query, and it doesn't seem to return even > after 15 minutes > Here is my query > > curl -XPOST "[http://xxxx/people/household/\_search?search\_type=count](http://xxxx/people/household/_search?search_type=count)" -d' > { > "query": { > "has\_child": { > "type": "person", > "query" : { > "filtered": { > "query": { "match\_all": {}}, > "filter" : { > "bool": { "must": [ > {"term": {"exact\_age": "65"}}, > {"term": {"gender": "m"}} > ] > } > } > } > } > } > } > }' > > Is there something I am doing wrong, is there a way to check what is > taking so long > > Thanks -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [June 20, 2013, 1:02pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/3 "2013-06-20T13:02:20Z")
Why not curl -XPOST "[http://xxxx/people/household/\_search?search\_type=count](http://xxxx/people/household/_search?search_type=count) [http://xxxx/people/household/\_search?search\_type=count](http://xxxx/people/household/_search?search_type=count)" -d' { "query": { "has\_child": { "type": "person", "query" : { "bool": { "must": [ {"term": {"exact\_age": "65"}}, {"term": {"gender": "m"}} ] } } } } }' Why 3 shards and not 1 on single node? Note that has\_child loads all \_id's on the heap, so adjust the heap size. You did not tell us about your heap settings. Jörg Am 20.06.13 14:53, schrieb David MZ: > UPDATE: my query returned taking 30 minutes > > On Thursday, June 20, 2013 3:05:01 PM UTC+3, David MZ wrote: > > ``` > I have a 40 million child documents with 20 million parents on 3 > shards all hosted within one machine > My specs are elastic 0.9, 8 cores, 8 gigs dedicated memory > > I am performing a has_child query, and it doesn't seem to return > even after 15 minutes > Here is my query > > curl -XPOST > "http://xxxx/people/household/_search?search_type=count > " -d' > { > "query": { > "has_child": { > "type": "person", > "query" : { > "filtered": { > "query": { "match_all": {}}, > "filter" : { > "bool": { "must": [ > {"term": {"exact_age": "65"}}, > {"term": {"gender": "m"}} > ] > } > } > } > } > } > } > }' > > Is there something I am doing wrong, is there a way to check what > is taking so long > > Thanks > > ``` > > -- > You received this message because you are subscribed to the Google > Groups "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![David\_MZ](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/david_mz/32/2215_2.png) [@David\_MZ](https://discuss.elastic.co/u/David_MZ)\ **Post date:** [June 20, 2013, 1:13pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/4 "2013-06-20T13:13:01Z")
I have 8 gigs for my heap (50% of the total ram), the issue is that I see in bigdesk that the memory climbs slowly to 7 gigs before the answer is given. but the query took 30 minutes so it seems that memory is not my bottleneck I was under the impression from reading that filtered query is the fastest query, I only need counting, also search\_type=count is suppose to be better the \_count On Thu, Jun 20, 2013 at 4:02 PM, Jörg Prante [joergprante@gmail.com](mailto:joergprante@gmail.com) wrote: > Why not > > curl -XPOST "[http://xxxx/people/household/\*\*\_search?search\_type=count](http://xxxx/people/household/**_search?search_type=count)[http://xxxx/people/household/\_search?search\_type=count](http://xxxx/people/household/_search?search_type=count)\< > [http://xxxx/people/household/\*\*\_search?search\_type=count](http://xxxx/people/household/**_search?search_type=count)[http://xxxx/people/household/\_search?search\_type=count](http://xxxx/people/household/_search?search_type=count)\>" > -d' > > { > "query": { > "has\_child": { > "type": "person", > "query" : { > "bool": { "must": [ > {"term": {"exact\_age": "65"}}, > {"term": {"gender": "m"}} > ] > } > } > } > } > }' > > Why 3 shards and not 1 on single node? > > Note that has\_child loads all \_id's on the heap, so adjust the heap size. > You did not tell us about your heap settings. > > Jörg > > Am 20.06.13 14:53, schrieb David MZ: > > > UPDATE: my query returned taking 30 minutes > > > > On Thursday, June 20, 2013 3:05:01 PM UTC+3, David MZ wrote: > > > > ``` > > I have a 40 million child documents with 20 million parents on 3 > > shards all hosted within one machine > > My specs are elastic 0.9, 8 cores, 8 gigs dedicated memory > > > > I am performing a has_child query, and it doesn't seem to return > > even after 15 minutes > > Here is my query > > > > curl -XPOST > > "http://xxxx/people/household/**_search?search_type=count > > >" > > > > ``` > > > > -d' > > { > > "query": { > > "has\_child": { > > "type": "person", > > "query" : { > > "filtered": { > > "query": { "match\_all": {}}, > > "filter" : { > > "bool": { "must": [ > > {"term": {"exact\_age": "65"}}, > > {"term": {"gender": "m"}} > > ] > > } > > } > > } > > } > > } > > } > > }' > > > > ``` > > Is there something I am doing wrong, is there a way to check what > > is taking so long > > > > Thanks > > > > ``` > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to elasticsearch+unsubscribe@\*\*[googlegroups.com](http://googlegroups.com)[elasticsearch%2Bunsubscribe@googlegroups.com](mailto:elasticsearch%2Bunsubscribe@googlegroups.com) > > . > > > > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > . > > -- > You received this message because you are subscribed to a topic in the > Google Groups "elasticsearch" group. > To unsubscribe from this topic, visit [https://groups.google.com/d/](https://groups.google.com/d/)\*\* > topic/elasticsearch/Pr0G-\*\*j10IaM/unsubscribe[https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe) > . > To unsubscribe from this group and all its topics, send an email to > elasticsearch+unsubscribe@\*\*[googlegroups.com](http://googlegroups.com)[elasticsearch%2Bunsubscribe@googlegroups.com](mailto:elasticsearch%2Bunsubscribe@googlegroups.com) > . > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > . -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [June 20, 2013, 1:43pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/5 "2013-06-20T13:43:37Z")
has\_child is always internally a filtered query. Read the docs > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. "The has\_child query works the same as the has\_child filter, by automatically wrapping the filter with a constant\_score (when using the default score type). " Of course filters can be fast, but the price is high. They are fast if you have enough memory and if all your doc terms and doc ids can be loaded into memory. If not, they do not warn you, they are just becoming very slow, because you just stress the JVM and the OS, and you have to trace the numbers in the monitoring tools to find out if your heap is really the problem, or if OS has a problem. So at first, just run un-filtered query to see if your query works. Later you can experiment with filters. I can't tell if 8g is enough. Many people do not use large heaps, they just add more nodes. 3 shards on 1 node are competing for the 8g. It means, you have 2.66g for many millions of children. Did you calculate the size per shard? So I assume with 1 shard per node you may be a little better for has\_child queries. Jörg Am 20.06.13 15:13, schrieb David MZ: > I was under the impression from reading that filtered query is the > fastest query, I only need counting, also search\_type=count is suppose > to be better the \_count -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![David\_MZ](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/david_mz/32/2215_2.png) [@David\_MZ](https://discuss.elastic.co/u/David_MZ)\ **Post date:** [June 20, 2013, 1:55pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/6 "2013-06-20T13:55:13Z")
"So at first, just run un-filtered query to see if your query works. Later you can experiment with filters." This query took 10 second curl -XPOST "xxx/\_search" -d' { "query": { "has\_child": { "type": "person", "query" : { ``` "match_all": {} } } ``` } } I will try to index with one shard, my performance goals are quite big, I need an under a second query for "bool" filters (range term and terms), I just need the count of the parents, nothing more. Any tips? ' On Thu, Jun 20, 2013 at 4:43 PM, Jörg Prante [joergprante@gmail.com](mailto:joergprante@gmail.com) wrote: > has\_child is always internally a filtered query. > > Read the docs [http://www.elasticsearch.org/](http://www.elasticsearch.org/)\*\* > guide/reference/query-dsl/has-\*\*child-query/[http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/](http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/) > > "The has\_child query works the same as the has\_child filter, by > automatically wrapping the filter with a constant\_score (when using the > default score type). " > > Of course filters can be fast, but the price is high. They are fast if you > have enough memory and if all your doc terms and doc ids can be loaded into > memory. If not, they do not warn you, they are just becoming very slow, > because you just stress the JVM and the OS, and you have to trace the > numbers in the monitoring tools to find out if your heap is really the > problem, or if OS has a problem. > > So at first, just run un-filtered query to see if your query works. Later > you can experiment with filters. > > I can't tell if 8g is enough. Many people do not use large heaps, they > just add more nodes. 3 shards on 1 node are competing for the 8g. It means, > you have 2.66g for many millions of children. Did you calculate the size > per shard? So I assume with 1 shard per node you may be a little better for > has\_child queries. > > Jörg > > Am 20.06.13 15:13, schrieb David MZ: > > I was under the impression from reading that filtered query is the > > > fastest query, I only need counting, also search\_type=count is suppose to > > be better the \_count > > -- > You received this message because you are subscribed to a topic in the > Google Groups "elasticsearch" group. > To unsubscribe from this topic, visit [https://groups.google.com/d/](https://groups.google.com/d/)\*\* > topic/elasticsearch/Pr0G-\*\*j10IaM/unsubscribe[https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe) > . > To unsubscribe from this group and all its topics, send an email to > elasticsearch+unsubscribe@\*\*[googlegroups.com](http://googlegroups.com)[elasticsearch%2Bunsubscribe@googlegroups.com](mailto:elasticsearch%2Bunsubscribe@googlegroups.com) > . > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > . -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![mattweber](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mattweber/32/44940_2.png) [@mattweber](https://discuss.elastic.co/u/mattweber)\ **Post date:** [June 20, 2013, 1:57pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/7 "2013-06-20T13:57:25Z")
I have ran into the same problem (not 30 minute queries, but slow). They are due to two things. The first is loading the ids into memory which is the bulk of the slowness. There is no avoiding this, use warmers to make sure these ids are already loaded before running your queries. The second problem I found if that the has\_child query loops over every single parent id no matter if 1 or 1M parents have been identified. I have started working on a patch for this that you can try if you like: [https://github.com/mattweber/elasticsearch/tree/haschildopt](https://github.com/mattweber/elasticsearch/tree/haschildopt) Thanks, Matt Weber On Thu, Jun 20, 2013 at 6:43 AM, Jörg Prante [joergprante@gmail.com](mailto:joergprante@gmail.com) wrote: > has\_child is always internally a filtered query. > > Read the docs [http://www.elasticsearch.org/](http://www.elasticsearch.org/)\*\* > guide/reference/query-dsl/has-\*\*child-query/[http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/](http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/) > > "The has\_child query works the same as the has\_child filter, by > automatically wrapping the filter with a constant\_score (when using the > default score type). " > > Of course filters can be fast, but the price is high. They are fast if you > have enough memory and if all your doc terms and doc ids can be loaded into > memory. If not, they do not warn you, they are just becoming very slow, > because you just stress the JVM and the OS, and you have to trace the > numbers in the monitoring tools to find out if your heap is really the > problem, or if OS has a problem. > > So at first, just run un-filtered query to see if your query works. Later > you can experiment with filters. > > I can't tell if 8g is enough. Many people do not use large heaps, they > just add more nodes. 3 shards on 1 node are competing for the 8g. It means, > you have 2.66g for many millions of children. Did you calculate the size > per shard? So I assume with 1 shard per node you may be a little better for > has\_child queries. > > Jörg > > Am 20.06.13 15:13, schrieb David MZ: > > I was under the impression from reading that filtered query is the > > > fastest query, I only need counting, also search\_type=count is suppose to > > be better the \_count > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elasticsearch+unsubscribe@\*\*[googlegroups.com](http://googlegroups.com)[elasticsearch%2Bunsubscribe@googlegroups.com](mailto:elasticsearch%2Bunsubscribe@googlegroups.com) > . > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > . -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![mattweber](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mattweber/32/44940_2.png) [@mattweber](https://discuss.elastic.co/u/mattweber)\ **Post date:** [June 20, 2013, 2:01pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/8 "2013-06-20T14:01:36Z")
BTW, keep an eye on this issue: > > > Currently the has\_child query loops over every single document of the parent typ…e looking for the parents matched in child query. In situations where the child query only matches few parents, this loop is expensive. > > I feel this loop can be eliminated or short-circuited early since we already know the matching parent ids (the keys of the uidToScore map). > > I am currently testing a few approaches and will submit a PR when ready. > > /cc @martijnvg @s1monw Thanks, Matt Weber On Thu, Jun 20, 2013 at 6:57 AM, Matt Weber [matt.weber@gmail.com](mailto:matt.weber@gmail.com) wrote: > I have ran into the same problem (not 30 minute queries, but slow). They > are due to two things. The first is loading the ids into memory which is > the bulk of the slowness. There is no avoiding this, use warmers to make > sure these ids are already loaded before running your queries. The second > problem I found if that the has\_child query loops over every single parent > id no matter if 1 or 1M parents have been identified. I have started > working on a patch for this that you can try if you like: > > [https://github.com/mattweber/elasticsearch/tree/haschildopt](https://github.com/mattweber/elasticsearch/tree/haschildopt) > > Thanks, > Matt Weber > > On Thu, Jun 20, 2013 at 6:43 AM, Jörg Prante [joergprante@gmail.com](mailto:joergprante@gmail.com)wrote: > > > has\_child is always internally a filtered query. > > > > Read the docs [http://www.elasticsearch.org/](http://www.elasticsearch.org/)\*\* > > guide/reference/query-dsl/has-\*\*child-query/[http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/](http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/) > > > > "The has\_child query works the same as the has\_child filter, by > > automatically wrapping the filter with a constant\_score (when using the > > default score type). " > > > > Of course filters can be fast, but the price is high. They are fast if > > you have enough memory and if all your doc terms and doc ids can be loaded > > into memory. If not, they do not warn you, they are just becoming very > > slow, because you just stress the JVM and the OS, and you have to trace the > > numbers in the monitoring tools to find out if your heap is really the > > problem, or if OS has a problem. > > > > So at first, just run un-filtered query to see if your query works. Later > > you can experiment with filters. > > > > I can't tell if 8g is enough. Many people do not use large heaps, they > > just add more nodes. 3 shards on 1 node are competing for the 8g. It means, > > you have 2.66g for many millions of children. Did you calculate the size > > per shard? So I assume with 1 shard per node you may be a little better for > > has\_child queries. > > > > Jörg > > > > Am 20.06.13 15:13, schrieb David MZ: > > > > I was under the impression from reading that filtered query is the > > > > > fastest query, I only need counting, also search\_type=count is suppose to > > > be better the \_count > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to elasticsearch+unsubscribe@\*\*[googlegroups.com](http://googlegroups.com)[elasticsearch%2Bunsubscribe@googlegroups.com](mailto:elasticsearch%2Bunsubscribe@googlegroups.com) > > . > > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > . -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![David\_MZ](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/david_mz/32/2215_2.png) [@David\_MZ](https://discuss.elastic.co/u/David_MZ)\ **Post date:** [June 20, 2013, 2:01pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/9 "2013-06-20T14:01:37Z")
I have 25 million parents and 45mil children, even after I run a second query with slight change in filters it took 30 minutes, so there is something wrong here, as the ids was suppose to be loaded but the sequential query also took a long time On Thu, Jun 20, 2013 at 4:57 PM, Matt Weber [matt.weber@gmail.com](mailto:matt.weber@gmail.com) wrote: > I have ran into the same problem (not 30 minute queries, but slow). They > are due to two things. The first is loading the ids into memory which is > the bulk of the slowness. There is no avoiding this, use warmers to make > sure these ids are already loaded before running your queries. The second > problem I found if that the has\_child query loops over every single parent > id no matter if 1 or 1M parents have been identified. I have started > working on a patch for this that you can try if you like: > > [https://github.com/mattweber/elasticsearch/tree/haschildopt](https://github.com/mattweber/elasticsearch/tree/haschildopt) > > Thanks, > Matt Weber > > On Thu, Jun 20, 2013 at 6:43 AM, Jörg Prante [joergprante@gmail.com](mailto:joergprante@gmail.com)wrote: > > > has\_child is always internally a filtered query. > > > > Read the docs [http://www.elasticsearch.org/](http://www.elasticsearch.org/)\*\* > > guide/reference/query-dsl/has-\*\*child-query/[http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/](http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/) > > > > "The has\_child query works the same as the has\_child filter, by > > automatically wrapping the filter with a constant\_score (when using the > > default score type). " > > > > Of course filters can be fast, but the price is high. They are fast if > > you have enough memory and if all your doc terms and doc ids can be loaded > > into memory. If not, they do not warn you, they are just becoming very > > slow, because you just stress the JVM and the OS, and you have to trace the > > numbers in the monitoring tools to find out if your heap is really the > > problem, or if OS has a problem. > > > > So at first, just run un-filtered query to see if your query works. Later > > you can experiment with filters. > > > > I can't tell if 8g is enough. Many people do not use large heaps, they > > just add more nodes. 3 shards on 1 node are competing for the 8g. It means, > > you have 2.66g for many millions of children. Did you calculate the size > > per shard? So I assume with 1 shard per node you may be a little better for > > has\_child queries. > > > > Jörg > > > > Am 20.06.13 15:13, schrieb David MZ: > > > > I was under the impression from reading that filtered query is the > > > > > fastest query, I only need counting, also search\_type=count is suppose to > > > be better the \_count > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to elasticsearch+unsubscribe@\*\*[googlegroups.com](http://googlegroups.com)[elasticsearch%2Bunsubscribe@googlegroups.com](mailto:elasticsearch%2Bunsubscribe@googlegroups.com) > > . > > > > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > . > > -- > You received this message because you are subscribed to a topic in the > Google Groups "elasticsearch" group. > To unsubscribe from this topic, visit > [https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe). > To unsubscribe from this group and all its topics, send an email to > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![David\_MZ](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/david_mz/32/2215_2.png) [@David\_MZ](https://discuss.elastic.co/u/David_MZ)\ **Post date:** [June 20, 2013, 2:04pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/10 "2013-06-20T14:04:30Z")
I do not need to get the parent documents only count them, is there anything I can do to make it faster On Thursday, June 20, 2013 5:01:37 PM UTC+3, David MZ wrote: > I have 25 million parents and 45mil children, even after I run a second > query with slight change in filters it took 30 minutes, so there is > something wrong here, as the ids was suppose to be loaded > > but the sequential query also took a long time > > On Thu, Jun 20, 2013 at 4:57 PM, Matt Weber [matt.weber@gmail.com](mailto:matt.weber@gmail.com) wrote: > > > I have ran into the same problem (not 30 minute queries, but slow). They > > are due to two things. The first is loading the ids into memory which is > > the bulk of the slowness. There is no avoiding this, use warmers to make > > sure these ids are already loaded before running your queries. The second > > problem I found if that the has\_child query loops over every single parent > > id no matter if 1 or 1M parents have been identified. I have started > > working on a patch for this that you can try if you like: > > > > [https://github.com/mattweber/elasticsearch/tree/haschildopt](https://github.com/mattweber/elasticsearch/tree/haschildopt) > > > > Thanks, > > Matt Weber > > > > On Thu, Jun 20, 2013 at 6:43 AM, Jörg Prante [joergprante@gmail.com](mailto:joergprante@gmail.com)wrote: > > > > > has\_child is always internally a filtered query. > > > > > > Read the docs [http://www.elasticsearch.org/](http://www.elasticsearch.org/)\*\* > > > guide/reference/query-dsl/has-\*\*child-query/[http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/](http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/) > > > > > > "The has\_child query works the same as the has\_child filter, by > > > automatically wrapping the filter with a constant\_score (when using the > > > default score type). " > > > > > > Of course filters can be fast, but the price is high. They are fast if > > > you have enough memory and if all your doc terms and doc ids can be loaded > > > into memory. If not, they do not warn you, they are just becoming very > > > slow, because you just stress the JVM and the OS, and you have to trace the > > > numbers in the monitoring tools to find out if your heap is really the > > > problem, or if OS has a problem. > > > > > > So at first, just run un-filtered query to see if your query works. > > > Later you can experiment with filters. > > > > > > I can't tell if 8g is enough. Many people do not use large heaps, they > > > just add more nodes. 3 shards on 1 node are competing for the 8g. It means, > > > you have 2.66g for many millions of children. Did you calculate the size > > > per shard? So I assume with 1 shard per node you may be a little better for > > > has\_child queries. > > > > > > Jörg > > > > > > Am 20.06.13 15:13, schrieb David MZ: > > > > > > I was under the impression from reading that filtered query is the > > > > > > > fastest query, I only need counting, also search\_type=count is suppose to > > > > be better the \_count > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > an email to elasticsearch+unsubscribe@\*\*[googlegroups.com](http://googlegroups.com)[elasticsearch%2Bunsubscribe@googlegroups.com](mailto:elasticsearch%2Bunsubscribe@googlegroups.com) > > > . > > > > > > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > > . > > > > -- > > You received this message because you are subscribed to a topic in the > > Google Groups "elasticsearch" group. > > To unsubscribe from this topic, visit > > [https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe). > > To unsubscribe from this group and all its topics, send an email to > > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![mattweber](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mattweber/32/44940_2.png) [@mattweber](https://discuss.elastic.co/u/mattweber)\ **Post date:** [June 20, 2013, 2:22pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/11 "2013-06-20T14:22:09Z")
There is no avoiding the loading, but the queries should be faster after the fact. Have you tried using a filter? It is generally faster than a query. { "query": { "constant\_score": { "filter": { "has\_child": { "filter": { "bool": { "must": [ {"term": {"exact\_age": "65"}}, {"term": {"gender": "m"}} ] } } } } } } } Thanks, Matt Weber On Thu, Jun 20, 2013 at 7:04 AM, David MZ [david.mazvovsky@gmail.com](mailto:david.mazvovsky@gmail.com) wrote: > I do not need to get the parent documents only count them, is there > anything I can do to make it faster > > On Thursday, June 20, 2013 5:01:37 PM UTC+3, David MZ wrote: > > > I have 25 million parents and 45mil children, even after I run a second > > query with slight change in filters it took 30 minutes, so there is > > something wrong here, as the ids was suppose to be loaded > > > > but the sequential query also took a long time > > > > On Thu, Jun 20, 2013 at 4:57 PM, Matt Weber [matt.weber@gmail.com](mailto:matt.weber@gmail.com) wrote: > > > > > I have ran into the same problem (not 30 minute queries, but slow). > > > They are due to two things. The first is loading the ids into memory > > > which is the bulk of the slowness. There is no avoiding this, use warmers > > > to make sure these ids are already loaded before running your queries. The > > > second problem I found if that the has\_child query loops over every single > > > parent id no matter if 1 or 1M parents have been identified. I have > > > started working on a patch for this that you can try if you like: > > > > > > [https://github.com/mattweber/\*\*elasticsearch/tree/haschildopt](https://github.com/mattweber/**elasticsearch/tree/haschildopt)[https://github.com/mattweber/elasticsearch/tree/haschildopt](https://github.com/mattweber/elasticsearch/tree/haschildopt) > > > > > > Thanks, > > > Matt Weber > > > > > > On Thu, Jun 20, 2013 at 6:43 AM, Jörg Prante [joergprante@gmail.com](mailto:joergprante@gmail.com)wrote: > > > > > > > has\_child is always internally a filtered query. > > > > > > > > Read the docs [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/**g)\*\* > > > > uide/reference/query-dsl/has- **c** hild-query/[http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/](http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/) > > > > > > > > "The has\_child query works the same as the has\_child filter, by > > > > automatically wrapping the filter with a constant\_score (when using the > > > > default score type). " > > > > > > > > Of course filters can be fast, but the price is high. They are fast if > > > > you have enough memory and if all your doc terms and doc ids can be loaded > > > > into memory. If not, they do not warn you, they are just becoming very > > > > slow, because you just stress the JVM and the OS, and you have to trace the > > > > numbers in the monitoring tools to find out if your heap is really the > > > > problem, or if OS has a problem. > > > > > > > > So at first, just run un-filtered query to see if your query works. > > > > Later you can experiment with filters. > > > > > > > > I can't tell if 8g is enough. Many people do not use large heaps, they > > > > just add more nodes. 3 shards on 1 node are competing for the 8g. It means, > > > > you have 2.66g for many millions of children. Did you calculate the size > > > > per shard? So I assume with 1 shard per node you may be a little better for > > > > has\_child queries. > > > > > > > > Jörg > > > > > > > > Am 20.06.13 15:13, schrieb David MZ: > > > > > > > > I was under the impression from reading that filtered query is the > > > > > > > > > fastest query, I only need counting, also search\_type=count is suppose to > > > > > be better the \_count > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to elasticsearch+unsubscribe@ **goog** [legroups.com](http://legroups.com)[elasticsearch%2Bunsubscribe@googlegroups.com](mailto:elasticsearch%2Bunsubscribe@googlegroups.com) > > > > . > > > > > > > > For more options, visit [https://groups.google.com/\*\*grou\*\*ps/opt\_out](https://groups.google.com/ **grou** ps/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > > > . > > > > > > -- > > > You received this message because you are subscribed to a topic in the > > > Google Groups "elasticsearch" group. > > > To unsubscribe from this topic, visit [https://groups.google.com/d/](https://groups.google.com/d/)\*\* > > > topic/elasticsearch/Pr0G-\*\*j10IaM/unsubscribe[https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe) > > > . > > > To unsubscribe from this group and all its topics, send an email to > > > elasticsearch+unsubscribe@\*\*[googlegroups.com](http://googlegroups.com)[elasticsearch%2Bunsubscribe@googlegroups.com](mailto:elasticsearch%2Bunsubscribe@googlegroups.com) > > > . > > > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > > . > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![David\_MZ](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/david_mz/32/2215_2.png) [@David\_MZ](https://discuss.elastic.co/u/David_MZ)\ **Post date:** [June 20, 2013, 2:35pm UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/12 "2013-06-20T14:35:09Z")
I tried both, there is no speed difference. I want to solve this issue, how can I use your patch, will it help me? On Thursday, June 20, 2013 5:22:09 PM UTC+3, Matt Weber wrote: > There is no avoiding the loading, but the queries should be faster after > the fact. Have you tried using a filter? It is generally faster than a > query. > > { > "query": { > "constant\_score": { > "filter": { > "has\_child": { > "filter": { > "bool": { > "must": [ > {"term": {"exact\_age": "65"}}, > {"term": {"gender": "m"}} > ] > } > } > } > } > } > } > } > > Thanks, > Matt Weber > > On Thu, Jun 20, 2013 at 7:04 AM, David MZ \<[david.m...@gmail.com](mailto:david.m...@gmail.com)\ > > > wrote: > > > I do not need to get the parent documents only count them, is there > > anything I can do to make it faster > > > > On Thursday, June 20, 2013 5:01:37 PM UTC+3, David MZ wrote: > > > > > I have 25 million parents and 45mil children, even after I run a second > > > query with slight change in filters it took 30 minutes, so there is > > > something wrong here, as the ids was suppose to be loaded > > > > > > but the sequential query also took a long time > > > > > > On Thu, Jun 20, 2013 at 4:57 PM, Matt Weber \<[matt....@gmail.com](mailto:matt....@gmail.com)\ > > > > > > > wrote: > > > > > > > I have ran into the same problem (not 30 minute queries, but slow). > > > > They are due to two things. The first is loading the ids into memory > > > > which is the bulk of the slowness. There is no avoiding this, use warmers > > > > to make sure these ids are already loaded before running your queries. The > > > > second problem I found if that the has\_child query loops over every single > > > > parent id no matter if 1 or 1M parents have been identified. I have > > > > started working on a patch for this that you can try if you like: > > > > > > > > [https://github.com/mattweber/\*\*elasticsearch/tree/haschildopt](https://github.com/mattweber/**elasticsearch/tree/haschildopt)[https://github.com/mattweber/elasticsearch/tree/haschildopt](https://github.com/mattweber/elasticsearch/tree/haschildopt) > > > > > > > > Thanks, > > > > Matt Weber > > > > > > > > On Thu, Jun 20, 2013 at 6:43 AM, Jörg Prante \<[joerg...@gmail.com](mailto:joerg...@gmail.com)\ > > > > > > > > > wrote: > > > > > > > > > has\_child is always internally a filtered query. > > > > > > > > > > Read the docs [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/**g)\*\* > > > > > uide/reference/query-dsl/has- **c** hild-query/[http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/](http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/) > > > > > > > > > > "The has\_child query works the same as the has\_child filter, by > > > > > automatically wrapping the filter with a constant\_score (when using the > > > > > default score type). " > > > > > > > > > > Of course filters can be fast, but the price is high. They are fast if > > > > > you have enough memory and if all your doc terms and doc ids can be loaded > > > > > into memory. If not, they do not warn you, they are just becoming very > > > > > slow, because you just stress the JVM and the OS, and you have to trace the > > > > > numbers in the monitoring tools to find out if your heap is really the > > > > > problem, or if OS has a problem. > > > > > > > > > > So at first, just run un-filtered query to see if your query works. > > > > > Later you can experiment with filters. > > > > > > > > > > I can't tell if 8g is enough. Many people do not use large heaps, they > > > > > just add more nodes. 3 shards on 1 node are competing for the 8g. It means, > > > > > you have 2.66g for many millions of children. Did you calculate the size > > > > > per shard? So I assume with 1 shard per node you may be a little better for > > > > > has\_child queries. > > > > > > > > > > Jörg > > > > > > > > > > Am 20.06.13 15:13, schrieb David MZ: > > > > > > > > > > I was under the impression from reading that filtered query is the > > > > > > > > > > > fastest query, I only need counting, also search\_type=count is suppose to > > > > > > be better the \_count > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "elasticsearch" group. > > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > > an email to elasticsearc...@ **goog** [legroups.com](http://legroups.com) \. > > > > > > > > > > For more options, visit [https://groups.google.com/\*\*grou\*\*ps/opt\_out](https://groups.google.com/ **grou** ps/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > > > > . > > > > > > > > -- > > > > You received this message because you are subscribed to a topic in the > > > > Google Groups "elasticsearch" group. > > > > To unsubscribe from this topic, visit [https://groups.google.com/d/](https://groups.google.com/d/)\*\* > > > > topic/elasticsearch/Pr0G-\*\*j10IaM/unsubscribe[https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe) > > > > . > > > > To unsubscribe from this group and all its topics, send an email to > > > > elasticsearc...@\*\*[googlegroups.com](http://googlegroups.com) \. > > > > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > > > . > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![mvg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mvg/32/98890_2.png) [@mvg](https://discuss.elastic.co/u/mvg)\ **Post date:** [June 25, 2013, 8:36am UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/13 "2013-06-25T08:36:45Z")
If you are using ES version 0.90.0, then I recommend to upgrade to ES version 0.90.1, memory usage have been improved. See this issue: > > > The id cache loads the ids of all documents. If we only load the parent ids, the…n we can reduce the memory usage of the parent/child support. > > Update: The amount of memory that will be reduced when upgrading to version \`0.90.1\` depends on the amount of child documents in an index. For example if you have one child doc for every parent doc, then it the memory usage of the id cache should be reduced by around half. The more child docs per parent doc the larger the difference. 15 to 30 minutes is a very long time, are you sure you configured a has\_child query in the warmer for the index you're using? > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. Matt's improvement to the has\_child query improves the query time in certain cases. For example when a few child documents match, then the execution of the has\_child can be short circuited. Depending on the number of parent document, the parent/child join can take a bug chuck of the query time. The parent/child feature scales, so by having more primary shards and adding more nodes, the query time should become acceptable. On 20 June 2013 16:35, David MZ [david.mazvovsky@gmail.com](mailto:david.mazvovsky@gmail.com) wrote: > I tried both, there is no speed difference. I want to solve this issue, > how can I use your patch, will it help me? > > On Thursday, June 20, 2013 5:22:09 PM UTC+3, Matt Weber wrote: > > > There is no avoiding the loading, but the queries should be faster after > > the fact. Have you tried using a filter? It is generally faster than a > > query. > > > > { > > "query": { > > "constant\_score": { > > "filter": { > > "has\_child": { > > "filter": { > > "bool": { > > "must": [ > > {"term": {"exact\_age": "65"}}, > > {"term": {"gender": "m"}} > > ] > > } > > } > > } > > } > > } > > } > > } > > > > Thanks, > > Matt Weber > > > > On Thu, Jun 20, 2013 at 7:04 AM, David MZ [david.m...@gmail.com](mailto:david.m...@gmail.com) wrote: > > > > > I do not need to get the parent documents only count them, is there > > > anything I can do to make it faster > > > > > > On Thursday, June 20, 2013 5:01:37 PM UTC+3, David MZ wrote: > > > > > > > I have 25 million parents and 45mil children, even after I run a > > > > second query with slight change in filters it took 30 minutes, so there is > > > > something wrong here, as the ids was suppose to be loaded > > > > > > > > but the sequential query also took a long time > > > > > > > > On Thu, Jun 20, 2013 at 4:57 PM, Matt Weber [matt....@gmail.com](mailto:matt....@gmail.com) wrote: > > > > > > > > > I have ran into the same problem (not 30 minute queries, but slow). > > > > > They are due to two things. The first is loading the ids into memory > > > > > which is the bulk of the slowness. There is no avoiding this, use warmers > > > > > to make sure these ids are already loaded before running your queries. The > > > > > second problem I found if that the has\_child query loops over every single > > > > > parent id no matter if 1 or 1M parents have been identified. I have > > > > > started working on a patch for this that you can try if you like: > > > > > > > > > > [https://github.com/mattweber/\*\*e\*\*lasticsearch/tree/haschildopt](https://github.com/mattweber/ **e** lasticsearch/tree/haschildopt)[https://github.com/mattweber/elasticsearch/tree/haschildopt](https://github.com/mattweber/elasticsearch/tree/haschildopt) > > > > > > > > > > Thanks, > > > > > Matt Weber > > > > > > > > > > On Thu, Jun 20, 2013 at 6:43 AM, Jörg Prante [joerg...@gmail.com](mailto:joerg...@gmail.com)wrote: > > > > > > > > > > > has\_child is always internally a filtered query. > > > > > > > > > > > > Read the docs [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/**g)\*\*\*\* > > > > > > uide/reference/query-dsl/has-\*\*c\*\*\*\*hild-query/[http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/](http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/) > > > > > > > > > > > > "The has\_child query works the same as the has\_child filter, by > > > > > > automatically wrapping the filter with a constant\_score (when using the > > > > > > default score type). " > > > > > > > > > > > > Of course filters can be fast, but the price is high. They are fast > > > > > > if you have enough memory and if all your doc terms and doc ids can be > > > > > > loaded into memory. If not, they do not warn you, they are just becoming > > > > > > very slow, because you just stress the JVM and the OS, and you have to > > > > > > trace the numbers in the monitoring tools to find out if your heap is > > > > > > really the problem, or if OS has a problem. > > > > > > > > > > > > So at first, just run un-filtered query to see if your query works. > > > > > > Later you can experiment with filters. > > > > > > > > > > > > I can't tell if 8g is enough. Many people do not use large heaps, > > > > > > they just add more nodes. 3 shards on 1 node are competing for the 8g. It > > > > > > means, you have 2.66g for many millions of children. Did you calculate the > > > > > > size per shard? So I assume with 1 shard per node you may be a little > > > > > > better for has\_child queries. > > > > > > > > > > > > Jörg > > > > > > > > > > > > Am 20.06.13 15:13, schrieb David MZ: > > > > > > > > > > > > I was under the impression from reading that filtered query is the > > > > > > > > > > > > > fastest query, I only need counting, also search\_type=count is suppose to > > > > > > > be better the \_count > > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > > Groups "elasticsearch" group. > > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > > send an email to elasticsearc...@\*\*goog\*\*\*\*[legroups.com](http://legroups.com). > > > > > > > > > > > > For more options, visit [https://groups.google.com/\*\*grou](https://groups.google.com/**grou)\*\*\*\* > > > > > > ps/opt\_out [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). > > > > > > > > > > -- > > > > > You received this message because you are subscribed to a topic in the > > > > > Google Groups "elasticsearch" group. > > > > > To unsubscribe from this topic, visit [https://groups.google.com/d/\*\*to](https://groups.google.com/d/**to) > > > > > \*\*pic/elasticsearch/Pr0G-\*\*j10IaM/\*\*unsubscribe[https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe) > > > > > . > > > > > To unsubscribe from this group and all its topics, send an email to > > > > > elasticsearc...@ **goog** [legroups.com](http://legroups.com). > > > > > > > > > > For more options, visit [https://groups.google.com/\*\*grou\*\*ps/opt\_out](https://groups.google.com/ **grou** ps/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > > > > . > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to elasticsearc...@\*\*[googlegroups.com](http://googlegroups.com). > > > > > > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > > . > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- Met vriendelijke groet, Martijn van Groningen -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![David\_MZ](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/david_mz/32/2215_2.png) [@David\_MZ](https://discuss.elastic.co/u/David_MZ)\ **Post date:** [June 25, 2013, 9:05am UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/14 "2013-06-25T09:05:06Z")
I have migrated to using nested documents, is solved all my problems including performance Thanks On Tue, Jun 25, 2013 at 11:36 AM, Martijn v Groningen \< [martijn.v.groningen@gmail.com](mailto:martijn.v.groningen@gmail.com)\> wrote: > If you are using ES version 0.90.0, then I recommend to upgrade to ES > version 0.90.1, memory usage have been improved. See this issue: > [Parent-Child: Improve memory usage id cache · Issue #3028 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/3028) > > 15 to 30 minutes is a very long time, are you sure you configured a > has\_child query in the warmer for the index you're using? > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/api/admin-indices-warmers/) > > Matt's improvement to the has\_child query improves the query time in > certain cases. For example when a few child documents match, then the > execution of the has\_child can be short circuited. > > Depending on the number of parent document, the parent/child join can take > a bug chuck of the query time. The parent/child feature scales, so by > having more primary shards and adding more nodes, the query time should > become acceptable. > > On 20 June 2013 16:35, David MZ [david.mazvovsky@gmail.com](mailto:david.mazvovsky@gmail.com) wrote: > > > I tried both, there is no speed difference. I want to solve this issue, > > how can I use your patch, will it help me? > > > > On Thursday, June 20, 2013 5:22:09 PM UTC+3, Matt Weber wrote: > > > > > There is no avoiding the loading, but the queries should be faster after > > > the fact. Have you tried using a filter? It is generally faster than a > > > query. > > > > > > { > > > "query": { > > > "constant\_score": { > > > "filter": { > > > "has\_child": { > > > "filter": { > > > "bool": { > > > "must": [ > > > {"term": {"exact\_age": "65"}}, > > > {"term": {"gender": "m"}} > > > ] > > > } > > > } > > > } > > > } > > > } > > > } > > > } > > > > > > Thanks, > > > Matt Weber > > > > > > On Thu, Jun 20, 2013 at 7:04 AM, David MZ [david.m...@gmail.com](mailto:david.m...@gmail.com) wrote: > > > > > > > I do not need to get the parent documents only count them, is there > > > > anything I can do to make it faster > > > > > > > > On Thursday, June 20, 2013 5:01:37 PM UTC+3, David MZ wrote: > > > > > > > > > I have 25 million parents and 45mil children, even after I run a > > > > > second query with slight change in filters it took 30 minutes, so there is > > > > > something wrong here, as the ids was suppose to be loaded > > > > > > > > > > but the sequential query also took a long time > > > > > > > > > > On Thu, Jun 20, 2013 at 4:57 PM, Matt Weber [matt....@gmail.com](mailto:matt....@gmail.com)wrote: > > > > > > > > > > > I have ran into the same problem (not 30 minute queries, but slow). > > > > > > They are due to two things. The first is loading the ids into memory > > > > > > which is the bulk of the slowness. There is no avoiding this, use warmers > > > > > > to make sure these ids are already loaded before running your queries. The > > > > > > second problem I found if that the has\_child query loops over every single > > > > > > parent id no matter if 1 or 1M parents have been identified. I have > > > > > > started working on a patch for this that you can try if you like: > > > > > > > > > > > > [https://github.com/mattweber/\*\*e\*\*lasticsearch/tree/haschildopt](https://github.com/mattweber/ **e** lasticsearch/tree/haschildopt)[https://github.com/mattweber/elasticsearch/tree/haschildopt](https://github.com/mattweber/elasticsearch/tree/haschildopt) > > > > > > > > > > > > Thanks, > > > > > > Matt Weber > > > > > > > > > > > > On Thu, Jun 20, 2013 at 6:43 AM, Jörg Prante [joerg...@gmail.com](mailto:joerg...@gmail.com)wrote: > > > > > > > > > > > > > has\_child is always internally a filtered query. > > > > > > > > > > > > > > Read the docs [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/**g)\*\*\*\* > > > > > > > uide/reference/query-dsl/has-\*\*c\*\*\*\*hild-query/[http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/](http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/) > > > > > > > > > > > > > > "The has\_child query works the same as the has\_child filter, by > > > > > > > automatically wrapping the filter with a constant\_score (when using the > > > > > > > default score type). " > > > > > > > > > > > > > > Of course filters can be fast, but the price is high. They are fast > > > > > > > if you have enough memory and if all your doc terms and doc ids can be > > > > > > > loaded into memory. If not, they do not warn you, they are just becoming > > > > > > > very slow, because you just stress the JVM and the OS, and you have to > > > > > > > trace the numbers in the monitoring tools to find out if your heap is > > > > > > > really the problem, or if OS has a problem. > > > > > > > > > > > > > > So at first, just run un-filtered query to see if your query works. > > > > > > > Later you can experiment with filters. > > > > > > > > > > > > > > I can't tell if 8g is enough. Many people do not use large heaps, > > > > > > > they just add more nodes. 3 shards on 1 node are competing for the 8g. It > > > > > > > means, you have 2.66g for many millions of children. Did you calculate the > > > > > > > size per shard? So I assume with 1 shard per node you may be a little > > > > > > > better for has\_child queries. > > > > > > > > > > > > > > Jörg > > > > > > > > > > > > > > Am 20.06.13 15:13, schrieb David MZ: > > > > > > > > > > > > > > I was under the impression from reading that filtered query is the > > > > > > > > > > > > > > > fastest query, I only need counting, also search\_type=count is suppose to > > > > > > > > be better the \_count > > > > > > > > > > > > > > -- > > > > > > > You received this message because you are subscribed to the Google > > > > > > > Groups "elasticsearch" group. > > > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > > > send an email to elasticsearc...@\*\*goog\*\*\*\*[legroups.com](http://legroups.com). > > > > > > > > > > > > > > For more options, visit [https://groups.google.com/\*\*grou](https://groups.google.com/**grou)\*\*\*\* > > > > > > > ps/opt\_out [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). > > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to a topic in > > > > > > the Google Groups "elasticsearch" group. > > > > > > To unsubscribe from this topic, visit [https://groups.google.com/d/](https://groups.google.com/d/)\*\* > > > > > > to\*\*pic/elasticsearch/Pr0G-\*\*j10IaM/\*\*unsubscribe[https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe) > > > > > > . > > > > > > To unsubscribe from this group and all its topics, send an email to > > > > > > elasticsearc...@ **goog** [legroups.com](http://legroups.com). > > > > > > > > > > > > For more options, visit [https://groups.google.com/\*\*grou\*\*ps/opt\_out](https://groups.google.com/ **grou** ps/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > > > > > . > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "elasticsearch" group. > > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > > an email to elasticsearc...@\*\*[googlegroups.com](http://googlegroups.com). > > > > > > > > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > > > . > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). > > -- > Met vriendelijke groet, > > Martijn van Groningen > > -- > You received this message because you are subscribed to a topic in the > Google Groups "elasticsearch" group. > To unsubscribe from this topic, visit > [https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe). > To unsubscribe from this group and all its topics, send an email to > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![mvg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mvg/32/98890_2.png) [@mvg](https://discuss.elastic.co/u/mvg)\ **Post date:** [June 26, 2013, 9:52am UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/15 "2013-06-26T09:52:44Z")
Yes, the nested query is much faster than the has\_child query, but less flexible than parent/child in general. If that is okay with you then nested is a good choice. On 25 June 2013 11:05, David MZ [david.mazvovsky@gmail.com](mailto:david.mazvovsky@gmail.com) wrote: > I have migrated to using nested documents, is solved all my problems > including performance > > Thanks > > On Tue, Jun 25, 2013 at 11:36 AM, Martijn v Groningen \< > [martijn.v.groningen@gmail.com](mailto:martijn.v.groningen@gmail.com)\> wrote: > > > If you are using ES version 0.90.0, then I recommend to upgrade to ES > > version 0.90.1, memory usage have been improved. See this issue: > > [Parent-Child: Improve memory usage id cache · Issue #3028 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/3028) > > > > 15 to 30 minutes is a very long time, are you sure you configured a > > has\_child query in the warmer for the index you're using? > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/api/admin-indices-warmers/) > > > > Matt's improvement to the has\_child query improves the query time in > > certain cases. For example when a few child documents match, then the > > execution of the has\_child can be short circuited. > > > > Depending on the number of parent document, the parent/child join can > > take a bug chuck of the query time. The parent/child feature scales, so by > > having more primary shards and adding more nodes, the query time should > > become acceptable. > > > > On 20 June 2013 16:35, David MZ [david.mazvovsky@gmail.com](mailto:david.mazvovsky@gmail.com) wrote: > > > > > I tried both, there is no speed difference. I want to solve this issue, > > > how can I use your patch, will it help me? > > > > > > On Thursday, June 20, 2013 5:22:09 PM UTC+3, Matt Weber wrote: > > > > > > > There is no avoiding the loading, but the queries should be faster > > > > after the fact. Have you tried using a filter? It is generally faster > > > > than a query. > > > > > > > > { > > > > "query": { > > > > "constant\_score": { > > > > "filter": { > > > > "has\_child": { > > > > "filter": { > > > > "bool": { > > > > "must": [ > > > > {"term": {"exact\_age": "65"}}, > > > > {"term": {"gender": "m"}} > > > > ] > > > > } > > > > } > > > > } > > > > } > > > > } > > > > } > > > > } > > > > > > > > Thanks, > > > > Matt Weber > > > > > > > > On Thu, Jun 20, 2013 at 7:04 AM, David MZ [david.m...@gmail.com](mailto:david.m...@gmail.com) wrote: > > > > > > > > > I do not need to get the parent documents only count them, is there > > > > > anything I can do to make it faster > > > > > > > > > > On Thursday, June 20, 2013 5:01:37 PM UTC+3, David MZ wrote: > > > > > > > > > > > I have 25 million parents and 45mil children, even after I run a > > > > > > second query with slight change in filters it took 30 minutes, so there is > > > > > > something wrong here, as the ids was suppose to be loaded > > > > > > > > > > > > but the sequential query also took a long time > > > > > > > > > > > > On Thu, Jun 20, 2013 at 4:57 PM, Matt Weber [matt....@gmail.com](mailto:matt....@gmail.com)wrote: > > > > > > > > > > > > > I have ran into the same problem (not 30 minute queries, but slow). > > > > > > > They are due to two things. The first is loading the ids into memory > > > > > > > which is the bulk of the slowness. There is no avoiding this, use warmers > > > > > > > to make sure these ids are already loaded before running your queries. The > > > > > > > second problem I found if that the has\_child query loops over every single > > > > > > > parent id no matter if 1 or 1M parents have been identified. I have > > > > > > > started working on a patch for this that you can try if you like: > > > > > > > > > > > > > > [https://github.com/mattweber/\*\*e\*\*lasticsearch/tree/haschildopt](https://github.com/mattweber/ **e** lasticsearch/tree/haschildopt)[https://github.com/mattweber/elasticsearch/tree/haschildopt](https://github.com/mattweber/elasticsearch/tree/haschildopt) > > > > > > > > > > > > > > Thanks, > > > > > > > Matt Weber > > > > > > > > > > > > > > On Thu, Jun 20, 2013 at 6:43 AM, Jörg Prante [joerg...@gmail.com](mailto:joerg...@gmail.com)wrote: > > > > > > > > > > > > > > > has\_child is always internally a filtered query. > > > > > > > > > > > > > > > > Read the docs [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/**g)\*\*\*\* > > > > > > > > uide/reference/query-dsl/has-\*\*c\*\*\*\*hild-query/[http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/](http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/) > > > > > > > > > > > > > > > > "The has\_child query works the same as the has\_child filter, by > > > > > > > > automatically wrapping the filter with a constant\_score (when using the > > > > > > > > default score type). " > > > > > > > > > > > > > > > > Of course filters can be fast, but the price is high. They are fast > > > > > > > > if you have enough memory and if all your doc terms and doc ids can be > > > > > > > > loaded into memory. If not, they do not warn you, they are just becoming > > > > > > > > very slow, because you just stress the JVM and the OS, and you have to > > > > > > > > trace the numbers in the monitoring tools to find out if your heap is > > > > > > > > really the problem, or if OS has a problem. > > > > > > > > > > > > > > > > So at first, just run un-filtered query to see if your query works. > > > > > > > > Later you can experiment with filters. > > > > > > > > > > > > > > > > I can't tell if 8g is enough. Many people do not use large heaps, > > > > > > > > they just add more nodes. 3 shards on 1 node are competing for the 8g. It > > > > > > > > means, you have 2.66g for many millions of children. Did you calculate the > > > > > > > > size per shard? So I assume with 1 shard per node you may be a little > > > > > > > > better for has\_child queries. > > > > > > > > > > > > > > > > Jörg > > > > > > > > > > > > > > > > Am 20.06.13 15:13, schrieb David MZ: > > > > > > > > > > > > > > > > I was under the impression from reading that filtered query is the > > > > > > > > > > > > > > > > > fastest query, I only need counting, also search\_type=count is suppose to > > > > > > > > > be better the \_count > > > > > > > > > > > > > > > > -- > > > > > > > > You received this message because you are subscribed to the Google > > > > > > > > Groups "elasticsearch" group. > > > > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > > > > send an email to elasticsearc...@\*\*goog\*\*\*\*[legroups.com](http://legroups.com). > > > > > > > > > > > > > > > > For more options, visit [https://groups.google.com/\*\*grou](https://groups.google.com/**grou)\*\*\*\* > > > > > > > > ps/opt\_out [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). > > > > > > > > > > > > > > -- > > > > > > > You received this message because you are subscribed to a topic in > > > > > > > the Google Groups "elasticsearch" group. > > > > > > > To unsubscribe from this topic, visit [https://groups.google.com/d/](https://groups.google.com/d/)\*\* > > > > > > > to\*\*pic/elasticsearch/Pr0G-\*\*j10IaM/\*\*unsubscribe[https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe) > > > > > > > . > > > > > > > To unsubscribe from this group and all its topics, send an email to > > > > > > > elasticsearc...@ **goog** [legroups.com](http://legroups.com). > > > > > > > > > > > > > > For more options, visit [https://groups.google.com/\*\*grou\*\*ps/opt\_out](https://groups.google.com/ **grou** ps/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > > > > > > . > > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > > Groups "elasticsearch" group. > > > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > > > an email to elasticsearc...@\*\*[googlegroups.com](http://googlegroups.com). > > > > > > > > > > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > > > > . > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). > > > > -- > > Met vriendelijke groet, > > > > Martijn van Groningen > > > > -- > > You received this message because you are subscribed to a topic in the > > Google Groups "elasticsearch" group. > > To unsubscribe from this topic, visit > > [https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe). > > To unsubscribe from this group and all its topics, send an email to > > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- Met vriendelijke groet, Martijn van Groningen -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:29am UTC](https://discuss.elastic.co/t/very-slow-has-child-query-for-large-index/12494/16 "2017-07-06T02:29:25Z")