cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Resolved] (CASSANDRA-9028) Optimize LIMIT execution to mitigate need for a full partition scan
Date Thu, 26 Mar 2015 10:49:53 GMT


Sylvain Lebresne resolved CASSANDRA-9028.
    Resolution: Not a Problem

> 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
>         Attachments: Data.1.json, Data.2.json, Data.3.json, test.ddl, tracing.out
> 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