Jeremiah Jordan created CASSANDRA-5406:
------------------------------------------
Summary: 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
