[
https://issues.apache.org/jira/browse/CASSANDRA-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717514#comment-17717514
]
Benjamin Lerer commented on CASSANDRA-15803:
--------------------------------------------
I realized that my previous comment was confusing and simply wrong on some
parts. The problem of trying to do too much multi-tasking. So I want to have
another round at it ;-)
When I mentioned row filtering I was thinking at things like {{CONTAINS}} or
{{CONTAINS KEY}} that can pottentially have to go through a large collections
but we do not use AF for that so please ignore my over-heating brain.
For me {{ALLOW FILTERING}} is wrong at multiple level. The idea behind SQL was
a separation of concerns a user could ask for some data and it is up to the
database system to return them in the most efficient way. Which could be
through filtering (scan) if it was the most cost efficient thing. Like the
query that [~smiklosovic] mentioned. Filtering is not necessary bad in itself,
which is I believe what [~jeromatron] has been trying to raise here.
> Separate out allow filtering scanning through a partition versus scanning
> over the table
> ----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-15803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15803
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
> Reporter: Jeremy Hanna
> Assignee: Stefan Miklosovic
> Priority: Normal
>
> Currently allow filtering can mean two things in the spirit of "avoid
> operations that don't seek to a specific row or sequential rows of data."
> First, it can mean scanning across the entire table to meet the criteria of
> the query. That's almost always a bad thing and should be discouraged or
> disabled (see CASSANDRA-8303). Second, it can mean filtering within a
> specific partition. For example, in a query you could specify the full
> partition key and if you specify a criterion on a non-key field, it requires
> allow filtering.
> The second reason to require allow filtering is significantly less work to
> scan through a partition. It is still extra work over seeking to a specific
> row and getting N sequential rows though. So while an application developer
> and/or operator needs to be cautious about this second type, it's not
> necessarily a bad thing, depending on the table and the use case.
> I propose that we separate the way to specify allow filtering across an
> entire table from specifying allow filtering across a partition in a
> backwards compatible way. One idea that was brought up in Slack in the
> cassandra-dev room was to have allow filtering mean the superset - scanning
> across the table. Then if you want to specify that you *only* want to scan
> within a partition you would use something like
> {{ALLOW FILTERING [WITHIN PARTITION]}}
> So it will succeed if you specify non-key criteria within a single partition,
> but fail with a message to say it requires the full allow filtering. This
> would allow for a backwards compatible full allow filtering while allowing a
> user to specify that they want to just scan within a partition, but error out
> if trying to scan a full table.
> This is potentially also related to the capability limitation framework by
> which operators could more granularly specify what features are allowed or
> disallowed per user, discussed in CASSANDRA-8303. This way an operator could
> disallow the more general allow filtering while allowing the partition scan
> (or disallow them both at their discretion).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
