{"action":"opened","issue":{"url":"https://api.github.com/repos/elastic/elasticsearch/issues/15799","labels_url":"https://api.github.com/repos/elastic/elasticsearch/issues/15799/labels{/name}","comments_url":"https://api.github.com/repos/elastic/elasticsearch/issues/15799/comments","events_url":"https://api.github.com/repos/elastic/elasticsearch/issues/15799/events","html_url":"https://github.com/elastic/elasticsearch/issues/15799","id":125237735,"number":15799,"title":"Paginate from _id","user":{"login":"rashidkpc","id":1250387,"avatar_url":"https://avatars.githubusercontent.com/u/1250387?v=3","gravatar_id":"","url":"https://api.github.com/users/rashidkpc","html_url":"https://github.com/rashidkpc","followers_url":"https://api.github.com/users/rashidkpc/followers","following_url":"https://api.github.com/users/rashidkpc/following{/other_user}","gists_url":"https://api.github.com/users/rashidkpc/gists{/gist_id}","starred_url":"https://api.github.com/users/rashidkpc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rashidkpc/subscriptions","organizations_url":"https://api.github.com/users/rashidkpc/orgs","repos_url":"https://api.github.com/users/rashidkpc/repos","events_url":"https://api.github.com/users/rashidkpc/events{/privacy}","received_events_url":"https://api.github.com/users/rashidkpc/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-01-06T18:51:25Z","updated_at":"2016-01-06T18:51:25Z","closed_at":null,"body":"Currently the `from` key on a request takes an integer and paging picks up after chopping off that number of results from the top of the queued result set.\r\n\r\nThis works well for static sets. However in high write load situations, in which we're sorting by time, it becomes a problem. We may end up with missing results that it seems should be there, but have a hard time expressing where we want the results to start.\r\n\r\nTake for example, a logging case in which I want to see the 10 records before and the 10 records after some event.\r\n\r\nI could read the time from the event, and do a sort in both directions. However I'd have to hope that 10 things didn't happen at the same time, common in say, error scenarios where a number of errors (eg, one per shard in a distributed system, all happen at exactly the same time. If that was the case there's a very good chance that my record wouldn't actually appear in the results. \r\n\r\nOf course we could say the time resolution wasn't high enough, or that events would be of arbitrary order anyway, but the goal here really is to make sure that our \"context\" event is included and the results around it are the same as they would be in any previous request.\r\n\r\nIdeally I could request the following, assuring that I get `event24587302` as the first result in the chronologically sorted list\r\n\r\n```\r\n{\r\n sort: { \"@timestamp\" : \"desc\" }, // And fire another with \"asc\" at the same time, in an _msearch\r\n from: \"event24587302\"\r\n}\r\n```"}}