# Has\_child performance - alternative implementation **URL:** \ **Category:** Elasticsearch\ **Created:** [June 25, 2014, 11:45am UTC](https://discuss.elastic.co/t/has-child-performance-alternative-implementation/18327 "2014-06-25T11:45:32Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Moran\_B](https://avatars.discourse-cdn.com/v4/letter/m/ee59a6/32.png) [@Moran\_B](https://discuss.elastic.co/u/Moran_B)\ **Post date:** [June 25, 2014, 11:45am UTC](https://discuss.elastic.co/t/has-child-performance-alternative-implementation/18327/1 "2014-06-25T11:45:32Z")
In the documentation it says that ALL parent IDs must be resident in memory, the question is why. Why can't the has\_child run the query per shard, load into memory all of the parent IDs that returned from the query and then use these to filter the parent docs. For some cases, the recall on the children would be much lower than the parents, hence, no need for caching the parent-child relation at all. Has this been tried? What are/were the considerations for implementing this as it is? -- 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). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/6d13b8fe-6d00-4090-b15d-5484729d6810%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/6d13b8fe-6d00-4090-b15d-5484729d6810%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Drew\_Kutcharian](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/drew_kutcharian/32/742_2.png) [@Drew\_Kutcharian](https://discuss.elastic.co/u/Drew_Kutcharian)\ **Post date:** [June 25, 2014, 8:50pm UTC](https://discuss.elastic.co/t/has-child-performance-alternative-implementation/18327/2 "2014-06-25T20:50:27Z")
I'm interested to find this out too. > On Jun 25, 2014, at 4:45 AM, Moran B [moran.benisty@gmail.com](mailto:moran.benisty@gmail.com) wrote: > > In the documentation it says that ALL parent IDs must be resident in memory, the question is why. > > Why can't the has\_child run the query per shard, load into memory all of the parent IDs that returned from the query and then use these to filter the parent docs. > For some cases, the recall on the children would be much lower than the parents, hence, no need for caching the parent-child relation at all. > > ## Has this been tried? What are/were the considerations for implementing this as it is? > > 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). > To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/6d13b8fe-6d00-4090-b15d-5484729d6810%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/6d13b8fe-6d00-4090-b15d-5484729d6810%40googlegroups.com). > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- 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). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/3FD5D7FE-9120-4BE7-A340-3BA70FE9449F%40venarc.com](https://groups.google.com/d/msgid/elasticsearch/3FD5D7FE-9120-4BE7-A340-3BA70FE9449F%40venarc.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**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, 1:19am UTC](https://discuss.elastic.co/t/has-child-performance-alternative-implementation/18327/3 "2017-07-06T01:19:41Z")