# Result window is too large, from + size must be less than or equal to: \[10000\] but was \[10050\]

**URL:** <https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-10050/124392>\
**Category:** Elasticsearch\
**Created:** [March 17, 2018, 7:12am UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-10050/124392 "2018-03-17T07:12:56Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![David\_Jacob](https://avatars.discourse-cdn.com/v4/letter/d/f17d59/32.png) [@David\_Jacob](https://discuss.elastic.co/u/David_Jacob)\
**Post date:** [March 17, 2018, 7:12am UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-10050/124392/1 "2018-03-17T07:12:56Z")

</div>

I am trying to do pagination for my data in elastic search. But I was not able fetch beyond 10000.

I found that it is doable through "top hits aggregation"

[https://www.elastic.co/guide/en/elasticsearch/reference/6.2/search-aggregations-metrics-top-hits-aggregation.html](https://www.elastic.co/guide/en/elasticsearch/reference/6.2/search-aggregations-metrics-top-hits-aggregation.html)

where I can set from+size greater than 10000.

I just want to verify that what I am doing for pagination is advisable way or not.

Please suggest.

---

<div class="post-metadata">

**Author:** ![yaauie](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yaauie/32/23363_2.png) [@yaauie](https://discuss.elastic.co/u/yaauie)\
**Post date:** [March 17, 2018, 8:50am UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-10050/124392/2 "2018-03-17T08:50:33Z")

</div>

By default the offset + limit is limited to 10,000. This can be modified at a cluster level, but I would seriously advise against doing do.

When paginating in this manner, Elasticsearch has to parse the query, build the search context, distribute the query to applicable shards, coalate the results, skip past `$offset` items, then read out `$limit` items and destroy the search context _for each page_ which means that the deeper we paginate, each page is more expensive than the page before it.

Oy.

The 10,000 limit is there for a reason.

Thankfully, Elasticsearch has a [scroll API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-scroll.html), which reuses search context and position from one request to the next. You should use it when you need to paginate deeply.

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [March 17, 2018, 9:12am UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-10050/124392/3 "2018-03-17T09:12:02Z")

</div>

To sum up:

- educate your users. You normally don't have to click 1000 times on "next page" to get the result you were looking for. Think about Google or Qwant. Do you often go more than page 1?
- add a way to change the sort order. So last page comes in first page.
- if your need is to extract all the data to do some other processing later, then as @yaauie said, scroll API is the way to go. It has a big advantage. When you scroll, whatever happens on your index (new documents added for example), you will get consistent results.
- if you really need to do deep pagination, look at the search\_after feature. It has been designed for that. Note that you can basically just do "next page" with that but not "go to page 1476".

HTH

---

<div class="post-metadata">

**Author:** ![David\_Jacob](https://avatars.discourse-cdn.com/v4/letter/d/f17d59/32.png) [@David\_Jacob](https://discuss.elastic.co/u/David_Jacob)\
**Post date:** [March 17, 2018, 11:35am UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-10050/124392/4 "2018-03-17T11:35:21Z")

</div>

Thank you @yaauie for the detailed explanation.

> > The 10,000 limit is there for a reason.

Yeah.. I get it. But I wonder why this limit is not applied for "top hits aggregation". I am able to get more than 10000 documents using top hits aggregation.

Is it because aggregations are handling in a better way than direct querying or Elasticsearch missed to validate window size in aggregations ?

Please help me to understand

Thank you once again 🙂

---

<div class="post-metadata">

**Author:** ![David\_Jacob](https://avatars.discourse-cdn.com/v4/letter/d/f17d59/32.png) [@David\_Jacob](https://discuss.elastic.co/u/David_Jacob)\
**Post date:** [March 17, 2018, 11:40am UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-10050/124392/5 "2018-03-17T11:40:17Z")

</div>

Thank you @dadonet for you precise explanation 🙂

Please help me to understand why the window size limit is not considered in "top hits aggregation". I am able to fetch more than 10000 docs using this aggregation.

It is because aggregations are better in handling it or elastic search missed to validate window size in aggregations.

Thanks in advance  
Have a great day @dadonet 🙂

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [March 17, 2018, 1:08pm UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-10050/124392/6 "2018-03-17T13:08:11Z")

</div>

This looks like a bug to me. @jimczi WDYT?

---

<div class="post-metadata">

**Author:** ![jimczi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jimczi/32/47985_2.png) [@jimczi](https://discuss.elastic.co/u/jimczi)\
**Post date:** [March 21, 2018, 11:16am UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-10050/124392/7 "2018-03-21T11:16:37Z")

</div>

I agree we should honor this setting in TopHitsAggregation. I opened [https://github.com/elastic/elasticsearch/issues/29190](https://github.com/elastic/elasticsearch/issues/29190) for this purpose.

---

<div class="post-metadata">

**Author:** ![jimczi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jimczi/32/47985_2.png) [@jimczi](https://discuss.elastic.co/u/jimczi)\
**Post date:** [March 22, 2018, 2:27pm UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-10050/124392/8 "2018-03-22T14:27:54Z")

</div>

I answered too quickly sorry. There's already a limit in the top\_hits aggregation that defaults to 100 called `index.max_inner_result_window`. Though this limit is per bucket so it is possible to return more than 10,000 documents if you return more than 100 buckets in a parent aggregation.

---

<div class="post-metadata">

**Author:** ![David\_Jacob](https://avatars.discourse-cdn.com/v4/letter/d/f17d59/32.png) [@David\_Jacob](https://discuss.elastic.co/u/David_Jacob)\
**Post date:** [March 26, 2018, 11:06am UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-10050/124392/9 "2018-03-26T11:06:30Z")

</div>

Oh ok..  
I am using elasticsearch 5.5 and that's why I was able to fetch.  
Thanks @jimczi@dadoonet for taking time to answer my question. 🙂  
Have a nice day.

---

<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:** [April 23, 2018, 11:06am UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-10050/124392/10 "2018-04-23T11:06:40Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
