cursors result in expensive server side state. if ordering is less important an alternative is to make cardinality queries cheaper and then allow the client to

cursors result in expensive server side state. if ordering is less important an alternative is to make cardinality queries cheaper and then allow the client to request sections thereby making the scheme stateless for the purposes of the server. so one query returns an approximate cardinality of the result set or a partition count based on approximate size of the result set and a fixed request response size. the second to n queries are gets, but the gets include the partition count and the partition requested. the server uses a hashing scheme to either reduce the input data used for the construction of the response or filtering of the response itself. use of numerical partition ids and hashing allows for the response to maintain consistency over time as well as pushing of the sharding/selection scheme as deep as necessary into the data layer to avoid scalability issues. requests that are too big are cancelled and given abuse points.