[
https://issues.apache.org/jira/browse/CASSANDRA-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremiah Jordan reassigned CASSANDRA-5406:
------------------------------------------
Assignee: Jeremiah Jordan
> 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
> Assignee: 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
