[jira] [Commented] (CASSANDRA-4986) Allow finer control of ALLOW FILTERING behavior
[
https://issues.apache.org/jira/browse/CASSANDRA-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14237701#comment-14237701
]
Sylvain Lebresne commented on CASSANDRA-4986:
-
[~michalm] is correct, but let me add on top of that that this ticket was open
a long time ago and there hasn't been any conscensus on it's usefulness. In
fact, I'm myself now not entirely convinced that we need that kind of
complexity. What could maybe make sense instead is a simple filtering warn
threshold the same way we have {{tombstone_warn_threshold}}.
Allow finer control of ALLOW FILTERING behavior
---
Key: CASSANDRA-4986
URL: https://issues.apache.org/jira/browse/CASSANDRA-4986
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Priority: Minor
Fix For: 3.0
CASSANDRA-4915 added {{ALLOW FILTERING}} to warn people when they do
potentially inefficient queries. However, as discussed in the former issue it
would be interesting to allow controlling that mode more precisely by
allowing something like:
{noformat}
... ALLOW FILTERING MAX 500
{noformat}
whose behavior would be that the query would be short-circuited if it filters
(i.e. read but discard from the ResultSet) more than 500 CQL3 rows.
There is however 2 details I'm not totally clear on:
# what to do exactly when we reach the max filtering allowed. Do we return
what we have so far, but then we need to have a way to say in the result set
that the query was short-circuited. Or do we just throw an exception
TooManyFiltered (simpler but maybe a little bit less useful).
# what about deleted records? Should we count them as 'filtered'? Imho the
logical thing is to not count them as filtered, since after all we filter
them out in the normal path (i.e. even when ALLOW FILTERING is not used).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-4986) Allow finer control of ALLOW FILTERING behavior
[
https://issues.apache.org/jira/browse/CASSANDRA-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14236960#comment-14236960
]
Rajanarayanan Thottuvaikkatumana commented on CASSANDRA-4986:
-
There is already a LIMIT keyword in the SELECT statement .Then why to introduce
another one such as MAX? Thanks
Allow finer control of ALLOW FILTERING behavior
---
Key: CASSANDRA-4986
URL: https://issues.apache.org/jira/browse/CASSANDRA-4986
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Priority: Minor
Fix For: 3.0
CASSANDRA-4915 added {{ALLOW FILTERING}} to warn people when they do
potentially inefficient queries. However, as discussed in the former issue it
would be interesting to allow controlling that mode more precisely by
allowing something like:
{noformat}
... ALLOW FILTERING MAX 500
{noformat}
whose behavior would be that the query would be short-circuited if it filters
(i.e. read but discard from the ResultSet) more than 500 CQL3 rows.
There is however 2 details I'm not totally clear on:
# what to do exactly when we reach the max filtering allowed. Do we return
what we have so far, but then we need to have a way to say in the result set
that the query was short-circuited. Or do we just throw an exception
TooManyFiltered (simpler but maybe a little bit less useful).
# what about deleted records? Should we count them as 'filtered'? Imho the
logical thing is to not count them as filtered, since after all we filter
them out in the normal path (i.e. even when ALLOW FILTERING is not used).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-4986) Allow finer control of ALLOW FILTERING behavior
[
https://issues.apache.org/jira/browse/CASSANDRA-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14236972#comment-14236972
]
Michał Michalski commented on CASSANDRA-4986:
-
From what I understand:
LIMIT defines the maximum number of rows we want to return. If there are rows
matching your query, they're guaranteed to be returned (up to the LIMIT), but
it may take a long time to find them all depending on the dataset size. You
will get correct result, but there's no guarantee on the execution time.
MAX defines the maximum number of rows we want to iterate over (even if none
of them was matching your query). Even if there are rows matching your query,
they might not be returned if it requires C* to iterate over too many ( MAX)
rows to find them. This guarantees that the execution time of your query will
not be worse than what it takes to iterate over MAX rows, but you might get
inaccurate result (assuming more useful implementation, see point 1 in
description).
Allow finer control of ALLOW FILTERING behavior
---
Key: CASSANDRA-4986
URL: https://issues.apache.org/jira/browse/CASSANDRA-4986
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Priority: Minor
Fix For: 3.0
CASSANDRA-4915 added {{ALLOW FILTERING}} to warn people when they do
potentially inefficient queries. However, as discussed in the former issue it
would be interesting to allow controlling that mode more precisely by
allowing something like:
{noformat}
... ALLOW FILTERING MAX 500
{noformat}
whose behavior would be that the query would be short-circuited if it filters
(i.e. read but discard from the ResultSet) more than 500 CQL3 rows.
There is however 2 details I'm not totally clear on:
# what to do exactly when we reach the max filtering allowed. Do we return
what we have so far, but then we need to have a way to say in the result set
that the query was short-circuited. Or do we just throw an exception
TooManyFiltered (simpler but maybe a little bit less useful).
# what about deleted records? Should we count them as 'filtered'? Imho the
logical thing is to not count them as filtered, since after all we filter
them out in the normal path (i.e. even when ALLOW FILTERING is not used).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
