[ https://issues.apache.org/jira/browse/CASSANDRA-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717514#comment-17717514 ]
Benjamin Lerer edited comment on CASSANDRA-15803 at 4/28/23 8:19 AM: --------------------------------------------------------------------- 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 is what [~jeromatron] has been trying to raise here. Cassandra does not have a proper query optimizer yet (it is one thing I believe will change soon) but if it had one, something like AF would not make sense at the query level anymore because a user will be less efficient than a proper optimizer at picking up the best access pattern. At this point we might still want to be able to configure some safety nets but that will be an operator level decision about what they believe is acceptable or not. I am not advocating for removing AF at this point. Only when we will have a proper optimizer. was (Author: blerer): 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. Cassandra does not have a proper query optimizer yet (it is one thing I believe will change soon) but if it had something like AF would not make sense at the query level anymore because a user will be less efficient than a proper optimizer at picking up the best access pattern. At this point we might still want to be able to configure some safety nets but that will be an operator level decision about what they believe is acceptable or not. I am not advocating for removing AF at this point only when we will have a proper optimizer. > 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