# Sorting by the opposite direction is very slow **URL:** \ **Category:** Elasticsearch\ **Created:** [October 11, 2018, 9:40pm UTC](https://discuss.elastic.co/t/sorting-by-the-opposite-direction-is-very-slow/152132 "2018-10-11T21:40:28Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Jason\_Baumgartner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jason_baumgartner/32/92716_2.png) [@Jason\_Baumgartner](https://discuss.elastic.co/u/Jason_Baumgartner)\ **Post date:** [October 11, 2018, 9:40pm UTC](https://discuss.elastic.co/t/sorting-by-the-opposite-direction-is-very-slow/152132/1 "2018-10-11T21:40:29Z")
I have an index where I used the new Lucene feature of indexing on a specific field. In my mapping, I have the following: "sort.field": "created\_utc", "sort.order": "desc", When I request documents using the same sort order, matches come back extremely fast. For example, I am searching Reddit submissions with an API I created: > [https://beta.pushshift.io/reddit/submission/search/?sort=desc&size=1&pretty=true&metadata=true](https://beta.pushshift.io/reddit/submission/search/?sort=desc&size=1&pretty=true&metadata=true) If you look at the metadata-\>elasticsearch-\>took value, this search completes in milliseconds. However, if I sort in the opposite direction, the search time is in seconds (usually over 10): > [https://beta.pushshift.io/reddit/submission/search/?sort=asc&size=1&pretty=true&metadata=true](https://beta.pushshift.io/reddit/submission/search/?sort=asc&size=1&pretty=true&metadata=true) From what I know about binary search, searching on a sorted array is a O(log N) operation. However, sorting in the opposite direction should also be nearly as fast. Is this a bug with Lucene's implementation of their index? ---
**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:** [October 15, 2018, 11:41am UTC](https://discuss.elastic.co/t/sorting-by-the-opposite-direction-is-very-slow/152132/2 "2018-10-15T11:41:50Z")
> From what I know about binary search, searching on a sorted array is a O(log N) operation. However, sorting in the opposite direction should also be nearly as fast. Is this a bug with Lucene's implementation of their index? Sorting the result of a search is not a binary search. We collect all documents that match the query in the order of their appearance in the index and keep track of the N best ones with a priority queue. If the index sort matches the search sort we can early terminate the query when N documents are collected, otherwise all documents must be collected. The reverse index sort order is the worst case since it requires to change the top N every time we visit a new document. There was some discussions to optimize this case in Lucene though ([[LUCENE-7482] Faster sorted index search for reverse order search - ASF JIRA](https://issues.apache.org/jira/browse/LUCENE-7482)) with some interesting ideas. The issue is quite old so it could be interesting to open a new one that focuses on reverse index sort. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [November 12, 2018, 11:52am UTC](https://discuss.elastic.co/t/sorting-by-the-opposite-direction-is-very-slow/152132/3 "2018-11-12T11:52:46Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.