cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Lerer (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10707) Add support for Group By to Select statement
Date Fri, 04 Mar 2016 10:57:41 GMT


Benjamin Lerer commented on CASSANDRA-10707:

{quote}I noticed that CQLLimits.forShortReadRetry() does not provide any limit on the number
of rows either.{quote}
It looks like I was really tired when I looked at the code :-(

{quote}Not sure about CQLGroupByLimits.forShortReadRetry(). I believe putting no limit on
the number of rows (and only on the group) might lead to OOM. In fact, I need to think more
carefully about this but I'm not 100% sure that the short read logic isn't throw off by the
fact that counted() returns a number of groups not rows.{quote}

I think my implementation for {{forShortReadRetry()}} is simply wrong. The goal of the short
read retry is to fetch the rows that were missing for a given partition due to short read.
As the number of rows to request is computed in {{ShortReadRowProtection:: moreContents}}
I believe that even in the case of {{GROUP BY}} we should use a {{CQLLimits}} to request the

> Add support for Group By to Select statement
> --------------------------------------------
>                 Key: CASSANDRA-10707
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL
>            Reporter: Benjamin Lerer
>            Assignee: Benjamin Lerer
> Now that Cassandra support aggregate functions, it makes sense to support {{GROUP BY}}
on the {{SELECT}} statements.
> It should be possible to group either at the partition level or at the clustering column
> {code}
> SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey;
> SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP BY partitionKey,
clustering0, clustering1; 
> {code}

This message was sent by Atlassian JIRA

View raw message