[jira] [Commented] (CASSANDRA-4915) CQL should prevent or warn about inefficient queries
[
https://issues.apache.org/jira/browse/CASSANDRA-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498119#comment-13498119
]
Jonathan Ellis commented on CASSANDRA-4915:
---
Okay, I think I'm on board with option 3.
How about {{WITH FILTERING ALLOWED}}? {{FULL SCAN}} is a bit misleading in the
indexed case. (And in the case of a simple {{SELECT *}}, which we wouldn't
require the modifier for.)
> CQL should prevent or warn about inefficient queries
>
>
> 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
[jira] [Commented] (CASSANDRA-4915) CQL should prevent or warn about inefficient queries
[
https://issues.apache.org/jira/browse/CASSANDRA-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498130#comment-13498130
]
Sylvain Lebresne commented on CASSANDRA-4915:
-
bq. How about WITH FILTERING ALLOWED?
Agreed, that's a better name.
> CQL should prevent or warn about inefficient queries
>
>
> 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
[jira] [Commented] (CASSANDRA-4915) CQL should prevent or warn about inefficient queries
[
https://issues.apache.org/jira/browse/CASSANDRA-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498239#comment-13498239
]
Edward Capriolo commented on CASSANDRA-4915:
I am unclear on what "WITH FILTERING ALLOWED" does. Is it a clause that must be
applied to let this query run? Or is it a clause that changes how the query
runs?
SELECT * FROM videos WHERE videoname = 'My funny cat' WITH FILTERING ALLOWED;
SELECT * FROM videos WHERE videoname = 'My funny cat' ;
I do agree that LIMIT is the wrong concept because that limits the result set
and that will not short-circuit a query.
A better syntax could be this:
SELECT * FROM videos WHERE videoname = 'My funny cat' WITH MAX_EXAMINED = 5;
Where MAX_EXAMINED would be a count of columns/rows? processed. Whenever we
iterate over more then MAX_EXAMINED we shout circuit and return what we have.
(which may be nothing)
> CQL should prevent or warn about inefficient queries
>
>
> 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
[jira] [Commented] (CASSANDRA-4915) CQL should prevent or warn about inefficient queries
[
https://issues.apache.org/jira/browse/CASSANDRA-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13499052#comment-13499052
]
Sylvain Lebresne commented on CASSANDRA-4915:
-
bq. Is it a clause that must be applied to let this query run?
Yes, that's the idea.
bq. Whenever we iterate over more then MAX_EXAMINED we shout circuit and return
what we have
That's a good idea. However I'd rather see it as a way to fine-tune the
behavior of the {{FILTERING ALLOWED}} idea above (even if at the end, we end up
with pretty much the same than what you suggest). Let me explain.
What I'd like to do is:
# refuse queres as they are today when they might involve "filtering" data. By
filtering here I mean that some records are read but discarded from the
resultSet.
# adds an {{ALLOW FILTERING}} syntax that "unlock" those queries (as in, allow
the query to run).
# when {{ALLOW FILTERING}} is used, allow to specify the maximum number of
filtered records with say {{ALLOW FILTERING MAX 500}}.
I believe we're reached concensus on 1., but basically the arguments are above.
Now 2.+ 3. is pretty much the equivalent of Ed's idea (more precisely, using
{{LIMIT X ALLOW FILTERING MAX Y}} would be the equivalent of {{LIMIT X
MAX_PREPARED X+Y}} if I understand Ed's proposal right). However, the reason
why I think we should allow 2. alone are that:
* I do think 2. is useful in it's own right. Or rather, you may have cases
where you want all results period. How course you could provide a very big
value for the max filtered, but that's lame. Or another way to put it is that
it's one thing to say "I understand this query may do some unknown amount of
useless work underneath but go ahead" and a slightly different one to control
exactly how much of that uselless work you allow.
* Part 3. is a bit of a break of the API abstraction. What I mean here is that
the actual behavior/result of a MAX_EXAMINED will depends on implementation
details. Say tomorrow we'll optimize somehow how much records are actually
examined to answer a query, then a query MAX_EXAMINED may return a different
result tomorrow even on the exact same setting. Part 2. doesn't have this
problem, and so while I'm good having 3. because I see how it can be useful,
I'd rather not have it alone.
* On the very practical side of things, part 3. is more complex to implement.
I'm pretty sure it'll require some storage engine change for instance. Also, I
think there is points to clarify: if you shortcut the query, how does the user
know if the query was shortcut or not? We can probably add some flag to the
ResultSet I suppose, or somethine else, but the point is that I'd rather take
the time to do that part right. Meaning that I think shoving it in 1.2.0 at
this point is imho a bad idea. So I'd rather do part 2. now, which I'm
confident is well defined, and improve with part 3. later.
> CQL should prevent or warn about inefficient queries
>
>
> 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
[jira] [Commented] (CASSANDRA-4915) CQL should prevent or warn about inefficient queries
[
https://issues.apache.org/jira/browse/CASSANDRA-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13499117#comment-13499117
]
Edward Capriolo commented on CASSANDRA-4915:
I agree on all counts.
Part 3's undefined nature makes it difficult to solve. I think it benefit in
very wide rows, or large collections. In a thrift slice today we have start,end
and size to constrain the problem.
> CQL should prevent or warn about inefficient queries
>
>
> 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
[jira] [Commented] (CASSANDRA-4915) CQL should prevent or warn about inefficient queries
[
https://issues.apache.org/jira/browse/CASSANDRA-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500124#comment-13500124
]
Jonathan Ellis commented on CASSANDRA-4915:
---
Tagging for 1.2 so we don't break working queries later.
> CQL should prevent or warn about inefficient queries
>
>
> Key: CASSANDRA-4915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4915
> Project: Cassandra
> Issue Type: Improvement
>Affects Versions: 0.8.0
>Reporter: Edward Capriolo
>Assignee: Sylvain Lebresne
> Fix For: 1.2.0 rc1
>
>
> 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
[jira] [Commented] (CASSANDRA-4915) CQL should prevent or warn about inefficient queries
[
https://issues.apache.org/jira/browse/CASSANDRA-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502687#comment-13502687
]
Sylvain Lebresne commented on CASSANDRA-4915:
-
We can. But unfortunately that doesn't work out of the box. Because if we scan
without index, we'll read the full internal row and we then need to be able to
extract the CQL3 rows within that that matches the filter. I'm attaching a
second patch that does exactly that (And I have a dtest to check that this work
as expected).
> CQL should prevent or warn about inefficient queries
>
>
> Key: CASSANDRA-4915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4915
> Project: Cassandra
> Issue Type: Improvement
>Affects Versions: 0.8.0
>Reporter: Edward Capriolo
>Assignee: Sylvain Lebresne
> Fix For: 1.2.0 rc1
>
> Attachments: 0001-4915.txt,
> 0002-Allow-non-indexed-expr-with-ALLOW-FILTERING.txt
>
>
> 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
[jira] [Commented] (CASSANDRA-4915) CQL should prevent or warn about inefficient queries
[
https://issues.apache.org/jira/browse/CASSANDRA-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502776#comment-13502776
]
Jonathan Ellis commented on CASSANDRA-4915:
---
It looks like this is reading entire rows into memory. If so let's just leave
the restriction in for 1.2.0 and push the predicate down into the scan for
1.2.x.
> CQL should prevent or warn about inefficient queries
>
>
> Key: CASSANDRA-4915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4915
> Project: Cassandra
> Issue Type: Improvement
>Affects Versions: 0.8.0
>Reporter: Edward Capriolo
>Assignee: Sylvain Lebresne
> Fix For: 1.2.0 rc1
>
> Attachments: 0001-4915.txt,
> 0002-Allow-non-indexed-expr-with-ALLOW-FILTERING.txt
>
>
> 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
[jira] [Commented] (CASSANDRA-4915) CQL should prevent or warn about inefficient queries
[
https://issues.apache.org/jira/browse/CASSANDRA-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502785#comment-13502785
]
Sylvain Lebresne commented on CASSANDRA-4915:
-
bq. It looks like this is reading entire rows into memory
It does and I'm fine leaving that second part to later.
> CQL should prevent or warn about inefficient queries
>
>
> Key: CASSANDRA-4915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4915
> Project: Cassandra
> Issue Type: Improvement
>Affects Versions: 0.8.0
>Reporter: Edward Capriolo
>Assignee: Sylvain Lebresne
> Fix For: 1.2.0 rc1
>
> Attachments: 0001-4915.txt,
> 0002-Allow-non-indexed-expr-with-ALLOW-FILTERING.txt
>
>
> 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
[jira] [Commented] (CASSANDRA-4915) CQL should prevent or warn about inefficient queries
[
https://issues.apache.org/jira/browse/CASSANDRA-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503021#comment-13503021
]
Jonathan Ellis commented on CASSANDRA-4915:
---
All right, let's just run with part 1 for now.
> CQL should prevent or warn about inefficient queries
>
>
> Key: CASSANDRA-4915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4915
> Project: Cassandra
> Issue Type: Improvement
>Affects Versions: 0.8.0
>Reporter: Edward Capriolo
>Assignee: Sylvain Lebresne
> Fix For: 1.2.0 rc1
>
> Attachments: 0001-4915.txt,
> 0002-Allow-non-indexed-expr-with-ALLOW-FILTERING.txt
>
>
> 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
