Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id ACA70DF6D for ; Tue, 6 Nov 2012 15:48:13 +0000 (UTC) Received: (qmail 28911 invoked by uid 500); 6 Nov 2012 15:48:13 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 28868 invoked by uid 500); 6 Nov 2012 15:48:13 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 28853 invoked by uid 99); 6 Nov 2012 15:48:13 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Nov 2012 15:48:13 +0000 Date: Tue, 6 Nov 2012 15:48:13 +0000 (UTC) From: "Sylvain Lebresne (JIRA)" To: commits@cassandra.apache.org Message-ID: <6844032.74825.1352216893242.JavaMail.jiratomcat@arcas> In-Reply-To: <1330669656.70760.1352151852373.JavaMail.jiratomcat@arcas> Subject: [jira] [Commented] (CASSANDRA-4915) CQL should force limit when query samples data. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491549#comment-13491549 ] Sylvain Lebresne commented on CASSANDRA-4915: --------------------------------------------- bq. What do you think about forcing the construct 'WHERE token(key)=0'? I don't think it solves the problem honestly. There is nothing in that telling you that we won't use an index to answer your query and that the query will almost surely timeout if you have lots of rows but little matching the "videoname = 'My funny cat'" predicate. And in fact when/if we support indexing on a clustering key component (videoname in that case), it will make complete sense to do an indexed query with a 'token(key) > 0' condition (meaning, we allow this for indexed queries today and that doesn't imply the query is a full scan). > CQL should force limit when query samples data. > ----------------------------------------------- > > Key: CASSANDRA-4915 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4915 > Project: Cassandra > Issue Type: Improvement > Affects Versions: 1.2.0 beta 1 > Reporter: Edward Capriolo > Priority: Minor > > When issuing a query like: > {noformat} > CREATE TABLE videos ( > videoid uuid, > videoname varchar, > username varchar, > description varchar, > tags varchar, > upload_date timestamp, > PRIMARY KEY (videoid,videoname) > ); > SELECT * FROM videos WHERE videoname = 'My funny cat'; > {noformat} > Cassandra samples some data using get_range_slice and then applies the query. > This is very confusing to me, because as an end user am not sure if the query is fast because Cassandra is performing an optimized query (over an index, or using a slicePredicate) or if cassandra is simple sampling some random rows and returning me some results. > My suggestions: > 1) force people to supply a LIMIT clause on any query that is going to > page over get_range_slice > 2) having some type of explain support so I can establish if this > query will work in the > I will champion suggestion 1) because CQL has put itself in a rather unique un-sql like position by applying an automatic limit clause without the user asking for them. I also do not believe the CQL language should let the user issue queries that will not work as intended with "larger-then-auto-limit" size data sets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira