|
|
|
|
|
by growse
2008 days ago
|
|
> So your customer, the person that paying you for your product, needs to wait for some number of synchronous reads. The customer is not always right. It's also not clear what the practical issue with sequential requests are? Multiple parallel requests may get caught in a rate limiter, and impose much more work on the backend than a cursor (multiple unnecessarysort/discards). It's not a given that spamming a service gets you all the data any faster than using a cursor. > With non-opaque offsets these can be done in parallel. If the typical request requires 4 pages, these can be done 4 at a time and of it is less than 4 pages those can be discarded. If the typical request requires 4 pages, then your page size is suboptimal. |
|