Yes, you CAN change the fetch size to adjust how many pages of results are returned. But, if you have a million rows, you may still do hundreds or thousands of queries, one after the next. Even if each is 1ms, it's going to take a long time.
What Dor suggested is generating a number of SELECT statements, each of which would return part of the table (using TOKEN()), that you can execute in parallel. This will end up being much faster than trying to tune the single SELECT. On Tue, Apr 26, 2022 at 7:35 AM 18624049226 <18624049...@163.com> wrote: > Thank you for your reply! > > What I want to know is that the data volume of this table is not massive. > If the logic of CQL cannot be modified, just inside Cassandra, are there > any parameters that can affect the behavior of this query? For example, the > fetchSize parameter of other databases? > 在 2022/4/26 21:18, Dor Laor 写道: > > select * reads all of the data from the cluster, obviously it would be bad > if you'll > run a single query and expect it to return 'fast'. The best way is to > divide the data > set into chunks which will be selected by the range ownership per node, so > you'll > be able to query in parallel the entire cluster and maximize the > parallelism. > > If needed, I can provide an example for this > > On Tue, Apr 26, 2022 at 3:48 PM 18624049226 <18624049...@163.com> wrote: > >> We have a business scenario. We must execute the following statement: >> >> select * from tbl; >> >> This CQL has no WHERE condition. >> >> What I want to ask is that if the data in this table is more than one >> million or more, what methods or parameters can improve the performance of >> this CQL? >> >
