10 ms·

I can understand it is expensive to maintain. But, how does cursors solve dynamically generated data? In fact, executing serially increases the chances on missi

I can understand it is expensive to maintain. But, how does cursors solve dynamically generated data? In fact, executing serially increases the chances on missing lot more dynamic data rather than getting all pages at once.

fiedzia 7y ago
You send a query. Service determines the is more than one page of data and last id from first page is X. Next request checks for data matching query and id>X. All it needs to do is find first page of results and check if there is a chance for next page. This means very little work needs to be done, and if some entries will be added or removed between requests, its not a problem. If you go to second page (id>X), and back (id<X) you may get different results, that's how changes are handled. Assuming you have index on id (or whatever parameters are used), this guarantees predictable response times. A cursor is usually just association of few parameters(query parameters, sort order and last id). With paginations you need to: - figure out how many results you have, which may require scanning all of them (very expensive) - handle case where client requested page one and then jumped to page 10000, which means you have to scan a lot of data to figure out what should be on that page (if it exists) - figure out what to do when client requests page 1, page2, page 1, while data changed. Do you cache results? (expensive, and leads to showing stale data), show different data (confusing for user, where is the thing I was just looking at gone? why things jump between pages? why last record from page one reappears on page 2?)