Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 14 Feb 2014 14:41:48 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12672900.1381267275130.43415.1392388908913@arcas>
In-Reply-To: <JIRA.12672900.1381267275130@arcas>
References: <JIRA.12672900.1381267275130@arcas>
Subject: [jira] [Commented] (CASSANDRA-6167) Add end-slice termination
 predicate
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Sylvain Lebresne commented on CASSANDRA-6167:
---------------------------------------------

bq.  it is almost always necessary to do two rounds trips with the current approach.

I suppose it's not entirely relevant to the overall scope but I'm curious, why is that (assuming you can cache the last computed aggregation and that whatever background thread you have can update that value)?

bq. Perhaps we could permit filtering based on the value of a static column by comparison to a non-static column

I though about that too and I agree that at least in this example that sounds a lot less bad. Though arguably that may not cover the full scope of 'termination predicate'. Might be good enough in practice, or useful anyway in its own right, I don't know.

bq. It would be very incorrect to assume that this ticket would only be used for aggregation.

I understand. I guess what I'm saying is that I'm really not convinced by the actual proposition here and that one sign that it may might not be "the way to go" would be to not be able to come with at least one convincing example that don't feel hackish. But I don't really disagree on the underlying idea of exposing finer ways to terminate slices :)

> Add end-slice termination predicate
> -----------------------------------
>
>                 Key: CASSANDRA-6167
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6167
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API, Core
>            Reporter: Tupshin Harper
>            Priority: Minor
>              Labels: ponies
>
> When doing performing storage-engine slices, it would sometimes be beneficial to have the slice terminate for other reasons other than number of columns or min/max cell name.
> Since we are able to look at the contents of each cell as we read it, this is potentially doable with very little overhead. 
> Probably more challenging than the storage-engine implementation itself, is to come up with appropriate CQL syntax (Thrift, should we decide to support it, would be trivial).
> Two possibilities ar
> 1) special where function:
> SELECT pk,event from cf WHERE pk IN (1,5,10,11) AND partition_predicate({predicate})
> or a bigger language change, but i think one I prefer. more like:
> 2) SELECT pk,event from cf where pk IN (1,5,10,11) UNTIL PARTITION event {predicate}
> Neither feels perfect, but I do like the fact that the second one at least clearly states what it is intended to do.
> By using "UNTIL PARTITION", we could re-use the UNTIL keyword to handle other kinds of early-termination of selects that the coordinator might be able to do, such as stop retrieving additional rows from shards after a particular criterion was met.


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)