# Clarification on has\_child filter memory requirements **URL:** \ **Category:** Elasticsearch\ **Created:** [June 19, 2014, 4:03am UTC](https://discuss.elastic.co/t/clarification-on-has-child-filter-memory-requirements/18197 "2014-06-19T04:03:23Z")\ **Posts on this page:** 6\ **Page:** 1
**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 19, 2014, 4:03am UTC](https://discuss.elastic.co/t/clarification-on-has-child-filter-memory-requirements/18197/1 "2014-06-19T04:03:23Z")
Based on the official docs ([http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-child-filter.html](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-child-filter.html)): {quote} memory considerations With the current implementation, all \_parent field values and all \_id field values of parent documents are loaded into memory (heap) via field data in order to support fast lookups, so make sure there is enough memory for it. {/quote} Does this mean that all the parent docs will be loaded into memory or the ones matching the filter? If the former is true, then it would mean that one should keep the size of the parent objects to minimum, right? In addition, say has\_child is a part of a conjunction (regular filter AND has\_child), would ES still load all the parent docs, or only the ones that matched the first filter? Thanks, Drew -- 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/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.com](https://groups.google.com/d/msgid/elasticsearch/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\ **Post date:** [June 20, 2014, 7:04am UTC](https://discuss.elastic.co/t/clarification-on-has-child-filter-memory-requirements/18197/2 "2014-06-20T07:04:12Z")
Hey, not all parent documents (and not the data), just their ids. Still this can accumulate, which is the reason why you should monitor the size of that data structure (exposed in the nodes stats). Hope that helps. --Alex On Thu, Jun 19, 2014 at 6:03 AM, Drew Kutcharian [drew@venarc.com](mailto:drew@venarc.com) wrote: > Based on the official docs ( > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-child-filter.html) > ): > > {quote} > memory considerations > > With the current implementation, all \_parent field values and all \_id > field values of parent documents are loaded into memory (heap) via field > data in order to support fast lookups, so make sure there is enough memory > for it. > {/quote} > > Does this mean that all the parent docs will be loaded into memory or the > ones matching the filter? If the former is true, then it would mean that > one should keep the size of the parent objects to minimum, right? In > addition, say has\_child is a part of a conjunction (regular filter AND > has\_child), would ES still load all the parent docs, or only the ones that > matched the first filter? > > Thanks, > > Drew > > -- > 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/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.com](https://groups.google.com/d/msgid/elasticsearch/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.com) > [https://groups.google.com/d/msgid/elasticsearch/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.com?utm_medium=email&utm_source=footer) > . > 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/CAGCwEM-%3Dvbk3BkFQBbuXybg\_-QX%3DEj6Rou2QMzqbzXUsbYJV8w%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAGCwEM-%3Dvbk3BkFQBbuXybg_-QX%3DEj6Rou2QMzqbzXUsbYJV8w%40mail.gmail.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 21, 2014, 5:32am UTC](https://discuss.elastic.co/t/clarification-on-has-child-filter-memory-requirements/18197/3 "2014-06-21T05:32:06Z")
Thanks Alex. What do you mean by "not all parent documents (and not the data), just their ids" what decides what which parent document ids get loaded? Also, this ids that get loaded are per query or they stay around longer? I ask because in our use case we're going to keep adding more and more parents and children. - Drew On Jun 20, 2014, at 12:04 AM, Alexander Reelsen [alr@spinscale.de](mailto:alr@spinscale.de) wrote: > Hey, > > not all parent documents (and not the data), just their ids. Still this can accumulate, which is the reason why you should monitor the size of that data structure (exposed in the nodes stats). > > Hope that helps. > > --Alex > > On Thu, Jun 19, 2014 at 6:03 AM, Drew Kutcharian [drew@venarc.com](mailto:drew@venarc.com) wrote: > Based on the official docs ([Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-child-filter.html)): > > {quote} > memory considerations > > With the current implementation, all \_parent field values and all \_id field values of parent documents are loaded into memory (heap) via field data in order to support fast lookups, so make sure there is enough memory for it. > {/quote} > > Does this mean that all the parent docs will be loaded into memory or the ones matching the filter? If the former is true, then it would mean that one should keep the size of the parent objects to minimum, right? In addition, say has\_child is a part of a conjunction (regular filter AND has\_child), would ES still load all the parent docs, or only the ones that matched the first filter? > > Thanks, > > Drew > > -- > 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/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.com](https://groups.google.com/d/msgid/elasticsearch/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.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/CAGCwEM-%3Dvbk3BkFQBbuXybg\_-QX%3DEj6Rou2QMzqbzXUsbYJV8w%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAGCwEM-%3Dvbk3BkFQBbuXybg_-QX%3DEj6Rou2QMzqbzXUsbYJV8w%40mail.gmail.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/E4598079-47FD-4B49-BE88-A0AE75E98622%40venarc.com](https://groups.google.com/d/msgid/elasticsearch/E4598079-47FD-4B49-BE88-A0AE75E98622%40venarc.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [June 21, 2014, 2:51pm UTC](https://discuss.elastic.co/t/clarification-on-has-child-filter-memory-requirements/18197/4 "2014-06-21T14:51:07Z")
I've updated the docs on memory usage with parent-child. Hopefully more understandable: > **[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. On 21 June 2014 07:32, Drew Kutcharian [drew@venarc.com](mailto:drew@venarc.com) wrote: > Thanks Alex. What do you mean by "not all parent documents (and not the > data), just their ids” what decides what which parent document ids get > loaded? Also, this ids that get loaded are per query or they stay around > longer? I ask because in our use case we’re going to keep adding more and > more parents and children. > > - Drew > > On Jun 20, 2014, at 12:04 AM, Alexander Reelsen [alr@spinscale.de](mailto:alr@spinscale.de) wrote: > > Hey, > > not all parent documents (and not the data), just their ids. Still this > can accumulate, which is the reason why you should monitor the size of that > data structure (exposed in the nodes stats). > > Hope that helps. > > --Alex > > On Thu, Jun 19, 2014 at 6:03 AM, Drew Kutcharian [drew@venarc.com](mailto:drew@venarc.com) wrote: > > > Based on the official docs ( > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-child-filter.html) > > ): > > > > {quote} > > memory considerations > > > > With the current implementation, all \_parent field values and all \_id > > field values of parent documents are loaded into memory (heap) via field > > data in order to support fast lookups, so make sure there is enough memory > > for it. > > {/quote} > > > > Does this mean that all the parent docs will be loaded into memory or the > > ones matching the filter? If the former is true, then it would mean that > > one should keep the size of the parent objects to minimum, right? In > > addition, say has\_child is a part of a conjunction (regular filter AND > > has\_child), would ES still load all the parent docs, or only the ones that > > matched the first filter? > > > > Thanks, > > > > Drew > > > > -- > > 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/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.com](https://groups.google.com/d/msgid/elasticsearch/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.com) > > [https://groups.google.com/d/msgid/elasticsearch/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.com?utm_medium=email&utm_source=footer) > > . > > 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/CAGCwEM-%3Dvbk3BkFQBbuXybg\_-QX%3DEj6Rou2QMzqbzXUsbYJV8w%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAGCwEM-%3Dvbk3BkFQBbuXybg_-QX%3DEj6Rou2QMzqbzXUsbYJV8w%40mail.gmail.com) > [https://groups.google.com/d/msgid/elasticsearch/CAGCwEM-%3Dvbk3BkFQBbuXybg\_-QX%3DEj6Rou2QMzqbzXUsbYJV8w%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAGCwEM-%3Dvbk3BkFQBbuXybg_-QX%3DEj6Rou2QMzqbzXUsbYJV8w%40mail.gmail.com?utm_medium=email&utm_source=footer) > . > 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/E4598079-47FD-4B49-BE88-A0AE75E98622%40venarc.com](https://groups.google.com/d/msgid/elasticsearch/E4598079-47FD-4B49-BE88-A0AE75E98622%40venarc.com) > [https://groups.google.com/d/msgid/elasticsearch/E4598079-47FD-4B49-BE88-A0AE75E98622%40venarc.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/E4598079-47FD-4B49-BE88-A0AE75E98622%40venarc.com?utm_medium=email&utm_source=footer) > . > > 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/CAPt3XKT6BZpigfSgSX%3DtEUM-JTUmLHWKKQ3AQwWKNyQ2Og3HGA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAPt3XKT6BZpigfSgSX%3DtEUM-JTUmLHWKKQ3AQwWKNyQ2Og3HGA%40mail.gmail.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 23, 2014, 8:27pm UTC](https://discuss.elastic.co/t/clarification-on-has-child-filter-memory-requirements/18197/5 "2014-06-23T20:27:05Z")
Thanks Clinton. One thing that's still a bit unclear is "how" these doc ids get loaded and stay loaded. Mainly, if you have a use case where you keep adding parent docs, would ES keep updating the cache per insert or per has\_child query time? On Jun 21, 2014, at 7:51 AM, Clinton Gormley [clint@traveljury.com](mailto:clint@traveljury.com) wrote: > I've updated the docs on memory usage with parent-child. Hopefully more understandable: > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-child-filter.html?1#_memory_considerations_8) > > On 21 June 2014 07:32, Drew Kutcharian [drew@venarc.com](mailto:drew@venarc.com) wrote: > Thanks Alex. What do you mean by "not all parent documents (and not the data), just their ids" what decides what which parent document ids get loaded? Also, this ids that get loaded are per query or they stay around longer? I ask because in our use case we're going to keep adding more and more parents and children. > > - Drew > > On Jun 20, 2014, at 12:04 AM, Alexander Reelsen [alr@spinscale.de](mailto:alr@spinscale.de) wrote: > > > Hey, > > > > not all parent documents (and not the data), just their ids. Still this can accumulate, which is the reason why you should monitor the size of that data structure (exposed in the nodes stats). > > > > Hope that helps. > > > > --Alex > > > > On Thu, Jun 19, 2014 at 6:03 AM, Drew Kutcharian [drew@venarc.com](mailto:drew@venarc.com) wrote: > > Based on the official docs ([Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-child-filter.html)): > > > > {quote} > > memory considerations > > > > With the current implementation, all \_parent field values and all \_id field values of parent documents are loaded into memory (heap) via field data in order to support fast lookups, so make sure there is enough memory for it. > > {/quote} > > > > Does this mean that all the parent docs will be loaded into memory or the ones matching the filter? If the former is true, then it would mean that one should keep the size of the parent objects to minimum, right? In addition, say has\_child is a part of a conjunction (regular filter AND has\_child), would ES still load all the parent docs, or only the ones that matched the first filter? > > > > Thanks, > > > > Drew > > > > -- > > 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/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.com](https://groups.google.com/d/msgid/elasticsearch/FE901831-FB74-4F89-A313-16C1C08BF0A5%40venarc.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/CAGCwEM-%3Dvbk3BkFQBbuXybg\_-QX%3DEj6Rou2QMzqbzXUsbYJV8w%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAGCwEM-%3Dvbk3BkFQBbuXybg_-QX%3DEj6Rou2QMzqbzXUsbYJV8w%40mail.gmail.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/E4598079-47FD-4B49-BE88-A0AE75E98622%40venarc.com](https://groups.google.com/d/msgid/elasticsearch/E4598079-47FD-4B49-BE88-A0AE75E98622%40venarc.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/CAPt3XKT6BZpigfSgSX%3DtEUM-JTUmLHWKKQ3AQwWKNyQ2Og3HGA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAPt3XKT6BZpigfSgSX%3DtEUM-JTUmLHWKKQ3AQwWKNyQ2Og3HGA%40mail.gmail.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/10CD9D82-9686-4931-BFA5-B476AFC158C3%40venarc.com](https://groups.google.com/d/msgid/elasticsearch/10CD9D82-9686-4931-BFA5-B476AFC158C3%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:20am UTC](https://discuss.elastic.co/t/clarification-on-has-child-filter-memory-requirements/18197/6 "2017-07-06T01:20:28Z")