[jira] [Resolved] (CASSANDRA-9028) Optimize LIMIT execution to mitigate need for a full partition scan

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

> Optimize LIMIT execution to mitigate need for a full partition scan
> -------------------------------------------------------------------
>
>                 Key: CASSANDRA-9028
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9028
>             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
(v6.3.4#6332)