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