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

**URL:** <https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-11001/63070>\
**Category:** Elasticsearch\
**Created:** [October 14, 2016, 4:39pm UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-11001/63070 "2016-10-14T16:39:37Z")\
**Posts on this page:** 1\
**Showing post:** 4

<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:** [October 15, 2016, 11:41am UTC](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-11001/63070/4 "2016-10-15T11:41:24Z")

</div>

> [@toxaco](#):
>
> it will: 1. take a long time. 2. run out of limit memory (depending on settings).

1. May be. May be not that longer that you can imagine.
2. I think it's wrong. The opposite is true. I mean that loading on the coordinated node 10k docs instead of 1m of docs for example will consume much less memory.

Once you get back 10k docs in your application, just stream them to the other process/destination you want.

> [@toxaco](#):
>
> if there is some error in between

What kind of error? You mean elasticsearch does not work anymore? Then you need to fix the root of the problem not trying to work around it.  
I think you are talking about something going wrong then in your own process, right?  
If so, you have to deal with that on your side.

> [@toxaco](#):
>
> When I say I can't start from let's say document number 12230 is because the FROM parameter in the Search only allows me to start under 10k because of this limitation.

Yes this not how Scroll is working. You never specify the `from`.

Basically, you run a search request. It returns 10m of docs and you start to scroll the result set from the beginning x docs per x docs.  
When you run the next scroll call, it asks for the next x docs you want.

That said, may be this new feature coming in 5.0 could help for your case?

> <https://github.com/elastic/elasticsearch/pull/18237>
>
> API:
> 
> \`\`\`
> curl -XGET 'localhost:9200/twitter/tweet/\_search?scroll=1m' -d '{
> …"slice": {
> "field": "\_uid", \<1\>
> "id": 0, \<2\>
> "max": 10 \<3\>
> },
> "query": {
> "match" : {
> "title" : "elasticsearch"
> }
> }
> }
> \`\`\`
> 
> \<1\> (optional) The field name used to do the slicing (\_uid by default)
> \<2\> The id of the slice
> 
> By default the splitting is done on the shards first and then locally on each shard using the \_uid field
> with the following formula:
> \`slice(doc) = floorMod(hashCode(doc.\_uid), max)\`
> For instance if the number of shards is equal to 2 and the user requested 4 slices then the slices 0 and 2 are assigned
> to the first shard and the slices 1 and 3 are assigned to the second shard.
> 
> Each scroll is independent and can be processed in parallel like any scroll request.
> 
> Closes #13494

Also this new feature could help to resume a scroll at some point. No date for this feature though. [Introduce a new `_last_modified` metafield · Issue #20859 · elastic/elasticsearch · GitHub](https://github.com/elastic/elasticsearch/issues/20859)

I hope this helps.

---

_[View the full topic](https://discuss.elastic.co/t/result-window-is-too-large-from-size-must-be-less-than-or-equal-to-10000-but-was-11001/63070)._