[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[ https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191520#comment-15191520 ] Pavel Trukhanov commented on CASSANDRA-6167: {code}LIMIT UNTIL condition {code}? > Add end-slice termination predicate > --- > > Key: CASSANDRA-6167 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6167 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Tupshin Harper >Priority: Minor > Labels: cql > > 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.3.4#6332)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[ https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191514#comment-15191514 ] Pavel Trukhanov commented on CASSANDRA-6167: As I understand it, it's kind of limit like but controllable by user. How about using LIMIT keyword but with condition rather than integer constant? > Add end-slice termination predicate > --- > > Key: CASSANDRA-6167 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6167 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Tupshin Harper >Priority: Minor > Labels: cql > > 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.3.4#6332)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[ https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15185556#comment-15185556 ] Pavel Trukhanov commented on CASSANDRA-6167: I wanted to vote for the issue but was not sure about the whole idea, though. So please consider this comment as a vote for this or something alike: bq. filtering based on the value of a static column by comparison to a non-static column > Add end-slice termination predicate > --- > > Key: CASSANDRA-6167 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6167 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Tupshin Harper >Priority: Minor > Labels: cql > > 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.3.4#6332)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[ https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14385542#comment-14385542 ] Robert Stupp commented on CASSANDRA-6167: - Ping on this one. Now that we have CASSANDRA-4914 and CASSANDRA-8053, it could be possible to add some kind of "row limit per CQL partition key" or "end aggregate calculation". WDYT? > 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: cql > > 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.3.4#6332)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[ https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901528#comment-13901528 ] Benedict commented on CASSANDRA-6167: - This new example doesn't seem to be a good argument for it. If you're attempting outlier detection, you expect it *not* to be present, and so will ordinarily read the whole 10k events. So it does not save you anything. > 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)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[ https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901526#comment-13901526 ] Tupshin Harper commented on CASSANDRA-6167: --- Sylvain: so given the complexity and ambiguity about best approach for my example above, I'll just return to the simple: Partition represents a slice of time-series events for a particular source Client wants to know if value >= X appeared in the last 10,000 events (or since time Y). Outlier detection is one reason. There are others. Currently we would either need to do a single large slice, and retrieve all 10,000 events even if the value was found in the first few, or get smaller batches and keep retrieving additional batches until the target value is found. No matter what the syntax or implementation is, I'm quite convinced in the utility of being able to short circuit reading from a partition. > 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)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[ https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901513#comment-13901513 ] Tupshin Harper commented on CASSANDRA-6167: --- That certainly has some appeal. Linking to CASSANDRA-6561 for reference. On the other hand, I'm increasingly a fan of scala/haskell style Either types, and if/when we get custom types, I would consider implementing this feature in terms such a disjoint union. > 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)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[ 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)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[ https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901459#comment-13901459 ] Benedict commented on CASSANDRA-6167: - It seems like this could be achieved today with static columns. Perhaps we could permit filtering based on the value of a static column by comparison to a non-static column, so that you have a static (time, aggregate), and you select from non-static all values > time; compose with aggregate and update. Of course, updating the value would need to be done via CAS to be safe. Note I'm not endorsing this, but this certainly seems less bad than abusing the type of the value column. > 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)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[ https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901454#comment-13901454 ] Tupshin Harper commented on CASSANDRA-6167: --- The example above shows how this feature would allow for efficient client-side aggregation without having to do two round trips from the client. What you describe is a variant that I use today. However, even caching the last aggregation value is clearly insufficient in a massively distributed environment. The assumption here is that you are likely to have had another process do the last aggregation, so it is almost always necessary to do two rounds trips with the current approach. I share your dislike the string abuse hack, and am very open to other suggestions. It is quite possible that this ticket should somehow be subsumed into CASSANDRA-4914, but not as an aggregate function that could be implemented, but instead by extending CASSANDRA-4914 to include partition slice termination functions. It would be very incorrect to assume that this ticket would only be used for aggregation. There are a lot of cases where I would want to slice backwards in time until event X occurred, where event X is determined by the value of the event itself. So, if 4914 became "Custom aggregate, filtering, and slice termination functions in CQL, then I would be all on board. But filtering is certainly not going to be sufficient as it implies that the nod would still have to read the entire partition (or explicitly specified portion of the partition) which is exactly the opposite of the goal here > 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)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[ https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901224#comment-13901224 ] Sylvain Lebresne commented on CASSANDRA-6167: - Playing devil's advocate here but why wouldn't you just store the last aggregated value in a separate table? Granted, that assume you know the last aggregation value which in theory means 2 reads, but in practice it doesn't sound particularly hard for clients to cache that last aggregated value (of course, you'd want to refresh that cached value at some frequency but that can be done in the background easily enough). Because my main problem with that example is that this sound a lot like a hack. If I store floats, I want evtval to be a float, not some string that I abuse to store an aggregation in the middle of other stuffs (because that's fairly error prone for any consumer of the table that don't care about the pre-computed aggregation). I really don't think we should "promote" such ways. Note that I understand it's "just an example", but it doesn't feels to me like we should add such a thing without a bunch of non-hacky examples of that being useful. Also, there is CASSANDRA-4914. Once we have that, you'd want to use it for aggregation. Even if you still want to do the incremental aggregation like in your example, you'll still really want to use CASSANDRA-4914 to aggregate the values 'since last aggregation'. And I don't really see how the idea of this could cleanly cohabit with CASSANDRA-4914 (while it's trivial if you just store/cache the aggregation separately). > 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)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[ https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901052#comment-13901052 ] Tupshin Harper commented on CASSANDRA-6167: --- Adding an example for how this could be used for efficient client-side implemented aggregation. Assume a CQL table with the following structure: CREATE TABLE t6167 ( uid text, evtts int, evtval text, PRIMARY KEY (uid, evtts) ) WITH CLUSTERING ORDER BY (evtts DESC) (In a real system, evtts would probably be a timeuuid to avoid risk of collisions) Assume data in that table for a single partition looks like uid | evtts | evtval -+---+ 1 | 7 |0.5 1 | 6 | -1.4 1 | 5 |0.3 1 | 4 | s5.1 1 | 3 |1.7 1 | 2 |1.3 1 | 1 |2.1 (Ignore the monotonically increasing timestamps. Here only for simplicity. Timeuuids, there would not do this, of course) So this structure is used to write new floats (only used as an example of arbitrary aggregation) Source events will write values such as 2.1 and 1.3 At read time, the logic would be as follows: you would get a slice of the partition from most recent (hence the DESC ordering) back to either beginning of the partition or the most recently written summation value (e.g. s5.1 and s4.5). With the syntax from option 2 above (and using % as a wildcard), you would get SELECT uid,evtts,evtval from t6167 where uid=1 and evtts < NOW() UNTIL PARTITION evtval='s%' Asuming NOW() >= 8, and the above data, this would return : uid | evtts | evtval -+---+ 1 | 7 |0.5 1 | 6 | -1.4 1 | 5 |0.3 1 | 4 | s5.1 At that point, the client would return evtval 4.5 by doing client-side agregation of those 4 rows. Then optionally, if enough time had elapsed since the last aggregation column to ensure no out of order delivery (business rule), then that same reader thread would write back a new aggregation value at an appropriate timestamp lagging behing the current time by the potential out-of-order delivery window. These writes would be inherently idemptotent, and hence race-condition free and could be easily tuned for delivery window and aggregation frequency to various workloads > 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)