{"action":"opened","issue":{"url":"https://api.github.com/repos/scylladb/scylla/issues/3742","repository_url":"https://api.github.com/repos/scylladb/scylla","labels_url":"https://api.github.com/repos/scylladb/scylla/issues/3742/labels{/name}","comments_url":"https://api.github.com/repos/scylladb/scylla/issues/3742/comments","events_url":"https://api.github.com/repos/scylladb/scylla/issues/3742/events","html_url":"https://github.com/scylladb/scylla/issues/3742","id":356520013,"node_id":"MDU6SXNzdWUzNTY1MjAwMTM=","number":3742,"title":"Allow the coordinator to over- or undershoot the page-size limits set by the client","user":{"login":"denesb","id":1389273,"node_id":"MDQ6VXNlcjEzODkyNzM=","avatar_url":"https://avatars2.githubusercontent.com/u/1389273?v=4","gravatar_id":"","url":"https://api.github.com/users/denesb","html_url":"https://github.com/denesb","followers_url":"https://api.github.com/users/denesb/followers","following_url":"https://api.github.com/users/denesb/following{/other_user}","gists_url":"https://api.github.com/users/denesb/gists{/gist_id}","starred_url":"https://api.github.com/users/denesb/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/denesb/subscriptions","organizations_url":"https://api.github.com/users/denesb/orgs","repos_url":"https://api.github.com/users/denesb/repos","events_url":"https://api.github.com/users/denesb/events{/privacy}","received_events_url":"https://api.github.com/users/denesb/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-09-03T14:07:08Z","updated_at":"2018-09-03T14:07:08Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Strict adherence to page-sizes hurts all stateful queries that select more than a single partition (IN queries and range scans).  This is because these queries potentially send multiple concurrent read-requests to replicas. When the cumulative size of the results returned from these requests exceeds the size limit set by the client, the coordinator discards all excess rows.\r\nAbove the wasted effort to produce those results, this means that on the next page, some replicas will receive read requests with positions that are before (behind) the read position of their saved readers and these saved readers will have to be dropped.\r\nThe solution to this problem is to make adhering to the user-set limit a best-effort. Allow the coordinator to over- or undershoot the limit as it sees fit to maximize performance and minimize waste. The CQL protocol explicitly allows this.\r\nImplement a limiting mechanism that is as friendly to stateful queries as possible, minimizing querier cache drops.\r\n\r\nNote:\r\n* That when talking about size limit, the row limits is meant. The internal size limit of 1MB should still be respected on the replicas.\r\n* Replicas should still each adhere to the user-set row limits strictly as responses of mismatching size from replicas would trigger needless reconciliations."}}
{"actor":{"display_login":"denesb"}}