cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6825) COUNT(*) with WHERE not finding all the matching rows
Date Tue, 01 Apr 2014 16:29:21 GMT


Tyler Hobbs commented on CASSANDRA-6825:

[~slebresne] the logic is primarily broken because it continues checking latter components
after it knows that the first component intersects.  For example, suppose you have a slice
of {{((1, 1), "")}}, min column names of {{(0, 2)}}, and max column names of {{(2, 3)}}. 
The first component of the slice start falls within the min/max range; the second component
does not.  Although the slice is _starting_ outside of the min/max range for the second component,
it should be considered intersecting because we'll accept other values for the second component
(for higher values of the first component).  The current logic sees that the second component
doesn't fall within min/max and considers it non-intersecting.

> COUNT(*) with WHERE not finding all the matching rows
> -----------------------------------------------------
>                 Key: CASSANDRA-6825
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: quad core Windows7 x64, single node cluster
> Cassandra 2.0.5
>            Reporter: Bill Mitchell
>            Assignee: Tyler Hobbs
>             Fix For: 2.0.7, 2.1 beta2
>         Attachments: cassandra.log,, 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

View raw message