cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5406) Allow CQL3 queries to do extra filter after getting the column slice on a composite primary key
Date Tue, 02 Apr 2013 16:43:16 GMT

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

Sylvain Lebresne commented on CASSANDRA-5406:
---------------------------------------------

While we've decided not to support this type of query as is, we could definitively support
it with the ALLOW FILTERING flag. I'll also note that without having looked closely, I'm pretty
sure some of the refactorings in CASSANDRA-5125 would make this easier.
                
> Allow CQL3 queries to do extra filter after getting the column slice on a composite primary
key
> -----------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-5406
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5406
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jeremiah Jordan
>            Priority: Minor
>
> Let the following work:
> {noformat}
> CREATE TABLE "ChequeDeDup2" (
>   "bucketId" int,
>   "transitAba" int,
>   "transitAccount" bigint,
>   "serialNo" int,
>   amount bigint,
>   "subjectId" uuid,
>   "channelInd" ascii,
>   "creditAba" int,
>   "creditAccount" bigint,
>   "sourceTs" timestamp,
>   PRIMARY KEY ("bucketId", "transitAba", "transitAccount", "serialNo", amount, "subjectId")
> )
> select * from "ChequeDeDup2" where "bucketId" = 198 and "transitAba" >= 101 and "transitAccount"
= 198 and "serialNo" = 1 and "amount" = -1 order by "transitAba" desc , "transitAccount" desc,
"serialNo" desc, amount desc, "subjectId" DESC limit 5;
> Bad Request: PRIMARY KEY part transitAccount cannot be restricted (preceding part transitAba
is either not restricted or by a non-EQ relation)
> {noformat}
> The assumption seems to be that it is better to serialize all the data with transitAba
>= 198 back to the client side.  But it is *less* efficient for the server to serialize
all this data back to the client than it is to execute subsequent filters.
> The user should be allowed to trade off the CPU cost of filtering the data on the server
side with the IO cost of serializing all that data.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message