[
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)
