[jira] [Updated] (CASSANDRA-9028) Optimize LIMIT execution to mitigate need for a full partition scan
[ https://issues.apache.org/jira/browse/CASSANDRA-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jonathan lacefield updated CASSANDRA-9028: -- Attachment: Data.3.json Data.2.json Data.1.json tracing.out test.ddl 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)
[jira] [Updated] (CASSANDRA-9028) Optimize LIMIT execution to mitigate need for a full partition scan
[ https://issues.apache.org/jira/browse/CASSANDRA-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jonathan lacefield updated CASSANDRA-9028: -- Summary: Optimize LIMIT execution to mitigate need for a full partition scan (was: Optimize LIMIT execution to take mitigate need for a full partition scan) 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 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)
[jira] [Updated] (CASSANDRA-9028) Optimize LIMIT execution to mitigate need for a full partition scan
[ https://issues.apache.org/jira/browse/CASSANDRA-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-9028: -- Fix Version/s: 3.0 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 Fix For: 3.0 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)
[jira] [Updated] (CASSANDRA-9028) Optimize LIMIT execution to mitigate need for a full partition scan
[ https://issues.apache.org/jira/browse/CASSANDRA-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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: https://issues.apache.org/jira/browse/CASSANDRA-9028 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 (v6.3.4#6332)
