As long as it is valid in the paging protocol to return a short page, but still say “there are more pages”, I think that is fine to do that. For an actual LIMIT that is part of the user query, I think the server must always have returned all data that fits into the LIMIT when all pages have been returned.
-Jeremiah On Jun 12, 2023 at 12:56:14 PM, Josh McKenzie <jmcken...@apache.org> wrote: > Yeah, my bad. I have paging on the brain. Seriously. > > I can't think of a use-case in which a LIMIT based on # bytes makes sense > from a user perspective. > > On Mon, Jun 12, 2023, at 1:35 PM, Jeff Jirsa wrote: > > > > On Mon, Jun 12, 2023 at 9:50 AM Benjamin Lerer <b.le...@gmail.com> wrote: > > If you have rows that vary significantly in their size, your latencies > could end up being pretty unpredictable using a LIMIT BY <row_count>. Being > able to specify a limit by bytes at the driver / API level would allow app > devs to get more deterministic results out of their interaction w/the DB if > they're looking to respond back to a client within a certain time frame and > / or determine next steps in the app (continue paging, stop, etc) based on > how long it took to get results back. > > > Are you talking about the page size or the LIMIT. Once the LIMIT is > reached there is no "continue paging". LIMIT is also at the CQL level not > at the driver level. > I can totally understand the need for a page size in bytes not for a LIMIT. > > > Would only ever EXPECT to see a page size in bytes, never a LIMIT > specifying bytes. > > I know the C-11745 ticket says LIMIT, too, but that feels very odd to me. > > >
