# Extremely slow has\_child query. greater than 10 seconds

**URL:** <https://discuss.elastic.co/t/extremely-slow-has-child-query-greater-than-10-seconds/27218>\
**Category:** Elasticsearch\
**Created:** [August 11, 2015, 7:36pm UTC](https://discuss.elastic.co/t/extremely-slow-has-child-query-greater-than-10-seconds/27218 "2015-08-11T19:36:56Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![emptyemail](https://avatars.discourse-cdn.com/v4/letter/e/6de8d8/32.png) [@emptyemail](https://discuss.elastic.co/u/emptyemail)\
**Post date:** [August 11, 2015, 7:36pm UTC](https://discuss.elastic.co/t/extremely-slow-has-child-query-greater-than-10-seconds/27218/1 "2015-08-11T19:36:56Z")

</div>

Hi. Having trouble scaling has\_child query

I am trying to search for all items that haven't been viewed by a user yet.

Assumtions:

- 3 million users
- 3 million items
- 10 thousand items viewed per user.

We have an **item** index with a child document **viewed\_by** for each user that viewed the item.

To query items that have not been seen yet we use

```auto
bool:
  must_not: [
    {has_child: {type: 'viewed_by', query: {term: viewed_by_user_id: CURRENT_USER_ID}}}
  ]

```

This kinda works, its not fast but it doesn't generate errors.

When we tried adding more parameters to the filter, to only exclude items with a particular status, searches stop scaling and start timing out, our timeout is set to 10 seconds.

```auto
bool:
  must_not: [
    {has_child: {type: 'viewed_by', query: {bool: {must: [
        {term: viewed_by_user_id: CURRENT_USER_ID}
        {term: status: 1}
    ]}}}}
  ]

```

During this time the node cpu is under 20% with plenty of available memory. The cluster has 16 servers with 32 cores and 60 gigs of ram. Heap is limited to 30g.

Any suggestions of how to fix or where to look to figure out why the cpu is so low?

Thanks in advance.

---

<div class="post-metadata">

**Author:** ![msimos](https://avatars.discourse-cdn.com/v4/letter/m/bb73d2/32.png) [@msimos](https://discuss.elastic.co/u/msimos)\
**Post date:** [August 12, 2015, 9:22pm UTC](https://discuss.elastic.co/t/extremely-slow-has-child-query-greater-than-10-seconds/27218/2 "2015-08-12T21:22:14Z")

</div>

Have you tried using eager\_global\_ordinals?

[https://www.elastic.co/guide/en/elasticsearch/guide/current/parent-child-performance.html](https://www.elastic.co/guide/en/elasticsearch/guide/current/parent-child-performance.html)

---

<div class="post-metadata">

**Author:** ![emptyemail](https://avatars.discourse-cdn.com/v4/letter/e/6de8d8/32.png) [@emptyemail](https://discuss.elastic.co/u/emptyemail)\
**Post date:** [August 12, 2015, 10:12pm UTC](https://discuss.elastic.co/t/extremely-slow-has-child-query-greater-than-10-seconds/27218/3 "2015-08-12T22:12:57Z")

</div>

Hi Mike, thanks for the suggestions I have not but I will. What concerns me  
though is that a simple has\_child works just fine, but a slightly more  
complicated one cripples the system. I would imagine that the cost of  
building the ordinals list is the same regardless of the query complexity.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 5, 2017, 11:56pm UTC](https://discuss.elastic.co/t/extremely-slow-has-child-query-greater-than-10-seconds/27218/4 "2017-07-05T23:56:06Z")

</div>