Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 28 Aug 2017 22:23:00 +0000 (UTC)
From: "Jon Haddad (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12639907.1364607796000.141342.1503958980274@Atlassian.JIRA>
In-Reply-To: <JIRA.12639907.1364607796000@Atlassian.JIRA>
References: <JIRA.12639907.1364607796000@Atlassian.JIRA> <JIRA.12639907.1364607796280@jira-lw-us.apache.org>
Subject: [jira] [Resolved] (CASSANDRA-5406) Allow CQL3 queries to do extra
 filter after getting the column slice on a composite primary key
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 28 Aug 2017 22:23:07 -0000


     [ https://issues.apache.org/jira/browse/CASSANDRA-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jon Haddad resolved CASSANDRA-5406.
-----------------------------------
    Resolution: Duplicate

This has worked for a while now with ALLOW FILTERING and I believe is the result of CASSANDRA-6377.  Closing out as a duplicate.

> 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 was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org