[
https://issues.apache.org/jira/browse/CASSANDRA-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13951706#comment-13951706
]
Bill Mitchell commented on CASSANDRA-6826:
------------------------------------------
I started working on a smaller testcase, but competing time pressures at work
put that effort on hold. In the meantime, I was able to work around this
problem by using LIMIT instead of fetch, iterating over the partitions, and
using a compound comparison in the WHERE clause to establish position for the
next query. This prompted me to open JAVA-295, as I had to abandon the
QueryBuilder in order to construct this WHERE clause.
When Cassandra 2.0.7 comes out, I will check if the fix to CASSANDRA-6825 also
fixes all the issue I found with the SELECT.
> Query returns different number of results depending on fetchsize
> ----------------------------------------------------------------
>
> Key: CASSANDRA-6826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6826
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: quad-core Windows 7 x64, single node cluster
> Cassandra 2.0.5
> Reporter: Bill Mitchell
> Assignee: Sylvain Lebresne
>
> I issue a query across the set of partitioned wide rows for one logical row,
> where s, l, and partition specify the composite primary key for the row:
> SELECT ec, ea, rd FROM sr WHERE s = ? and partition IN ? and l = ? ALLOW
> FILTERING;
> If I set fetchSize to only 1000 when the Cluster is configured, the query
> sometimes does not return all the results. In the particular case I am
> chasing, it returns a total of 98586 rows. If I increase the fetchsize to
> 100000, all the 99999 actual rows are returned. This suggests there is some
> problem with fetchsize re-establishing the position on the next segment of
> the result set, at least when multiple partitions are being accessed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
