[ 
https://issues.apache.org/jira/browse/CASSANDRA-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942232#comment-13942232
 ] 

Bill Mitchell commented on CASSANDRA-6825:
------------------------------------------

I can confirm the problem is still there in 2.0.6.  As I was verifying that I 
could still reproduce CASSANDRA-6826, I checked for the COUNT(*) issue too.  In 
one of the tables six partitions, a COUNT(*) reported 10000 rows, but if I did 
a SELECT * in either ascending or descending order, cqlsh printed 20000 rows.  
Would it help if I zipped up the data directory containing the table after the 
problem appeared?  Or would you need other information from the system 
directory, too, to see how the data is recorded? That might help in isolating 
how the problem arises.

> COUNT(*) with WHERE not finding all the matching rows
> -----------------------------------------------------
>
>                 Key: CASSANDRA-6825
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6825
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: quad core Windows7 x64, single node cluster
> Cassandra 2.0.5
>            Reporter: Bill Mitchell
>            Assignee: Russ Hatch
>         Attachments: cassandra.log, selectpartitions.zip, selectrowcounts.txt
>
>
> Investigating another problem, I needed to do COUNT(*) on the several 
> partitions of a table immediately after a test case ran, and I discovered 
> that count(*) on the full table and on each of the partitions returned 
> different counts.  
> In particular case, SELECT COUNT(*) FROM sr LIMIT 1000000; returned the 
> expected count from the test 99999 rows.  The composite primary key splits 
> the logical row into six distinct partitions, and when I issue a query asking 
> for the total across all six partitions, the returned result is only 83999.  
> Drilling down, I find that SELECT * from sr WHERE s = 5 AND l = 11 AND 
> partition = 0; returns 30,000 rows, but a SELECT COUNT(*) with the identical 
> WHERE predicate reports only 14,000. 
> This is failing immediately after running a single small test, such that 
> there are only two SSTables, sr-jb-1 and sr-jb-2.  Compaction never needed to 
> run.  
> In selectrowcounts.txt is a copy of the cqlsh output showing the incorrect 
> count(*) results.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to