Docs: Updated the explanation about memory usage with parent/child

docs/reference/query-dsl/filters/has-child-filter.asciidoc

@@ -75,13 +75,24 @@ is specified.
 [float]
 ==== 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.
+In order to support parent-child joins, all of the (string) parent IDs 
+must be resident in memory (in the <<index-modules-fielddata,field data cache>>. 
+Additionaly, every child document is mapped to its parent using a long 
+value (approximately). It is advisable to keep the string parent ID short
+in order to reduce memory usage.
+
+You can check how much memory is being used by the ID cache using the
+<<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
+APIS, eg:
+
+[source,js]
+--------------------------------------------------
+curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
+--------------------------------------------------
 
 [float]
 ==== Caching
 
 The `has_child` filter cannot be cached in the filter cache. The `_cache`
 and `_cache_key` options are a no-op in this filter. Also any filter that
-wraps the `has_child` filter either directly or indirectly will not be cached.
+wraps the `has_child` filter either directly or indirectly will not be cached.

docs/reference/query-dsl/filters/has-parent-filter.asciidoc

@@ -46,11 +46,22 @@ The `has_parent` filter also accepts a filter instead of a query:
 --------------------------------------------------
 
 [float]
-==== Memory considerations
+==== 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.
+In order to support parent-child joins, all of the (string) parent IDs 
+must be resident in memory (in the <<index-modules-fielddata,field data cache>>. 
+Additionaly, every child document is mapped to its parent using a long 
+value (approximately). It is advisable to keep the string parent ID short
+in order to reduce memory usage.
+
+You can check how much memory is being used by the ID cache using the
+<<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
+APIS, eg:
+
+[source,js]
+--------------------------------------------------
+curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
+--------------------------------------------------
 
 [float]
 ==== Caching

docs/reference/query-dsl/queries/has-child-query.asciidoc

@@ -86,6 +86,19 @@ the `score_mode` parameter.
 [float]
 ==== 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.
+In order to support parent-child joins, all of the (string) parent IDs 
+must be resident in memory (in the <<index-modules-fielddata,field data cache>>. 
+Additionaly, every child document is mapped to its parent using a long 
+value (approximately). It is advisable to keep the string parent ID short
+in order to reduce memory usage.
+
+You can check how much memory is being used by the ID cache using the
+<<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
+APIS, eg:
+
+[source,js]
+--------------------------------------------------
+curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
+--------------------------------------------------
+
+

docs/reference/query-dsl/queries/has-parent-query.asciidoc

@@ -52,6 +52,19 @@ matching parent document. The score type can be specified with the
 [float]
 ==== 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.
+In order to support parent-child joins, all of the (string) parent IDs 
+must be resident in memory (in the <<index-modules-fielddata,field data cache>>. 
+Additionaly, every child document is mapped to its parent using a long 
+value (approximately). It is advisable to keep the string parent ID short
+in order to reduce memory usage.
+
+You can check how much memory is being used by the ID cache using the
+<<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
+APIS, eg:
+
+[source,js]
+--------------------------------------------------
+curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
+--------------------------------------------------
+
+

docs/reference/query-dsl/queries/top-children-query.asciidoc

@@ -66,6 +66,19 @@ same scope name that will work against the child documents. For example:
 [float]
 ==== 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.
+In order to support parent-child joins, all of the (string) parent IDs 
+must be resident in memory (in the <<index-modules-fielddata,field data cache>>. 
+Additionaly, every child document is mapped to its parent using a long 
+value (approximately). It is advisable to keep the string parent ID short
+in order to reduce memory usage.
+
+You can check how much memory is being used by the ID cache using the
+<<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
+APIS, eg:
+
+[source,js]
+--------------------------------------------------
+curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
+--------------------------------------------------
+
+