# \[Just Pushed\]: Search scroll support

**URL:** <https://discuss.elastic.co/t/just-pushed-search-scroll-support/2856>\
**Category:** Elasticsearch\
**Created:** [March 20, 2010, 11:17pm UTC](https://discuss.elastic.co/t/just-pushed-search-scroll-support/2856 "2010-03-20T23:17:36Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [March 20, 2010, 11:17pm UTC](https://discuss.elastic.co/t/just-pushed-search-scroll-support/2856/1 "2010-03-20T23:17:36Z")

</div>

See here: [http://github.com/elasticsearch/elasticsearch/issues/issue/77](http://github.com/elasticsearch/elasticsearch/issues/issue/77).  
Basically allows to continue and scroll a search request quite easily, with  
faster execution then if executing the search again. It comes at the expense  
of resources used to maintain the scrolling state on each node.

Note also, that scrolling is in a point in time (the time the first search  
was executed) scrolling. Any changes applied to the index, even with a  
refresh, will not be taken into account when scrolling (which is what you  
would want). This guarantees that unique results will be returned. Think of  
it as opening a cursor in database lingo.

-shay.banon

---

<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 6, 2017, 4:25am UTC](https://discuss.elastic.co/t/just-pushed-search-scroll-support/2856/2 "2017-07-06T04:25:12Z")

</div>


