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

Sylvain Lebresne commented on CASSANDRA-12102:
----------------------------------------------

We actually do index decisions multiple times, on both coordinator (since we do 
have some validation that depends on the index) and replicas. And I agree that 
it would nice to avoid that. Ideally, we'd etablish some kind of "query plan" 
on the coordinator (that plan would neatly separate what parts are done by 
which index (it could be even relatively extensible for custome index so they 
can ship whatever info they want for use on the replicas)), what is filtered, 
...), and ship that plan with the {{ReadCommand}}.

That would be nice. However, that definitively means a messaging chance, so 
that's at best a 4.x patch. It also probably have a non-empty intersection with 
CASSANDRA-10765, so we should make sure to discuss this generally before 
rushing into any of those ticket.


> 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)

Reply via email to