[
https://issues.apache.org/jira/browse/CASSANDRA-9928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15341188#comment-15341188
]
Matthias Broecheler commented on CASSANDRA-9928:
------------------------------------------------
Requiring that all non-PK columns that are indexed be updated at the same time
is too much of a limitation and will be really hard for users to understand
imho.
Instead, I would propose that we introduce a rate-change limit on the columns
that participate in an MV. If we can guarantee that there is a limit on the
number of changes to those columns than we can limit the number of distinct
state permutations that may need to be considered in the scenarios above. In
those cases, we would simply enumerate them and then delete all possible old MV
states.This sounds expensive but it would only be expensive when change happen
in fast succession or under extraordinary operational conditions - i.e. the
cost should amortize well.
As for the rate limit, it seems that this would be a rather arbitrary
limitation but if somebody changes their MV columns in rapid succession then
they are pursuing an anti-pattern and throwing an exception would be a better
response that deteriorating system performance.
> Add Support for multiple non-primary key columns in Materialized View primary
> keys
> ----------------------------------------------------------------------------------
>
> Key: CASSANDRA-9928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9928
> Project: Cassandra
> Issue Type: Improvement
> Reporter: T Jake Luciani
> Labels: materializedviews
> Fix For: 3.x
>
>
> Currently we don't allow > 1 non primary key from the base table in a MV
> primary key. We should remove this restriction assuming we continue
> filtering out nulls. With allowing nulls in the MV columns there are a lot
> of multiplicative implications we need to think through.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
