[jira] [Comment Edited] (CASSANDRA-12102) Refactor and simplify Filtering-related StatementRestriction part

["Alex Petrov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-12102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15364211#comment-15364211 ] 

Alex Petrov edited comment on CASSANDRA-12102 at 7/6/16 12:06 PM:
------------------------------------------------------------------

bq. We actually do index decisions multiple times, on both coordinator (since we do have some validation that depends on the index) and replicas

I thought that after [CASSANDRA-10215], since index name is serialised as a part of {{ReadCommand}}, it was already completely covered on the coordinator. Might be that [this|https://github.com/apache/cassandra/commit/e097efc5f6f76a0da8d15b307301dffff79e4a35#diff-861bc950c82973fb8f97f179e35be7f3R322] condition is what you had in mind. 

bq. we'd establish some kind of "query plan" on the coordinator

That was exactly what [~blerer] said when we talked about: to introduce the query planner. 

In general, I agree on the fact it'd have to wait until the protocol version bump and have an intersection with [CASSANDRA-10765].


was (Author: ifesdjeen):
> We actually do index decisions multiple times, on both coordinator (since we do have some validation that depends on the index) and replicas

I thought that after [CASSANDRA-10215], since index name is serialized as a part of {{ReadCommand}}, it was already completely covered on the coordinator. Might be that [this|https://github.com/apache/cassandra/commit/e097efc5f6f76a0da8d15b307301dffff79e4a35#diff-861bc950c82973fb8f97f179e35be7f3R322] condition is what you had in mind. 

> we'd etablish some kind of "query plan" on the coordinator

That was exactly what [~blerer] said when we talked about: to introduce the query planner. 

In general, I agree on the fact it'd have to wait until the protocol version bump and have an intersection with [CASSANDRA-10765].

> Refactor and simplify Filtering-related StatementRestriction part
> -----------------------------------------------------------------
>
>                 Key: CASSANDRA-12102
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12102
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Alex Petrov
>
> {{RestrictionSet}} hierarchy was significantly improved by [CASSANDRA-11354], although filtering-related {{Restrictions}} are split with restrictions that would go through the 2i already in {{RowFilter}}. 
> There's still a clear separation, although it's currently made in {{Index}} implementations and {{RowFilter}}, by removing things that were handled by {{Index}} for post-filtering like it's done [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ReadCommand.java#L374-L378]. 
> The primary concern is that we've seen several times that there are many corner-cases, so we may benefit from splitting columns that are handled by the index from ones that are handled by post-filtering early in code and possibly keeping them split for all parts of query. 
> I suggest to split {{ClusteringColumnRestrictions#addRowFilterTo}} into two parts, {{addIndexRestrictions}} and {{addFilteringRestrictions}}. The change should be quite simple and make the code simpler to understand and extend the filtering / indexing rules.
> -One problem, as noted by [~blerer] is that index decision is made on replica, depending on cardinality, so splitting them too early might not work.- the decision is actually made on the coordinator after [CASSANDRA-10215], although that might involve a larger refactoring, although might still help to keep code related to indexing / filtering together.
> We can also validate that all restrictions have been respected (although we can do that now as well).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)