cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-9028) Optimize LIMIT execution to mitigate need for a full partition scan
Date Tue, 24 Mar 2015 18:14:53 GMT


Jonathan Ellis updated CASSANDRA-9028:
    Fix Version/s:     (was: 3.0)

> Optimize LIMIT execution to mitigate need for a full partition scan
> -------------------------------------------------------------------
>                 Key: CASSANDRA-9028
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API, Core
>            Reporter: jonathan lacefield
> Currently, a SELECT statement for a single Partition Key that contains a LIMIT X clause
will fetch an entire partition from a node and place the partition into memory prior to applying
the limit clause and returning results to be served to the client via the coordinator.
> This JIRA is to request an optimization for the CQL LIMIT clause to avoid the entire
partition retrieval step, and instead only retrieve the components to satisfy the LIMIT condition.
> Ideally, any LIMIT X would avoid the need to retrieve a full partition.  This may not
be possible though.  As a compromise, it would still be incredibly beneficial if a LIMIT 1
clause could be optimized to only retrieve the "latest" item.  Ideally a LIMIT 1 would "operationally
behave" the same way as a Clustering Key WHERE clause where the "latest", i.e. LIMIT 1 field,
col value was specified.
> We can supply some trace results to help show the difference between 2 different queries
that preform the same logical function if desired.
>   For example, a query that returns the latest value for a clustering col where QUERY
1 uses a LIMIT 1 clause and QUERY 2 uses a WHERE <clustering col> = <latest value>

This message was sent by Atlassian JIRA

View raw message