[
https://issues.apache.org/jira/browse/CASSANDRA-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14624198#comment-14624198
]
Jonathan Ellis commented on CASSANDRA-9779:
-------------------------------------------
bq. IMO it would be logical to disallow UPDATE for WITH INSERTS ONLY tables
I guess I don't care if we disallow UPDATE; my larger point is that the normal
semantics of INSERT allow UPDATE-like behavior, so we need to redefine those
slightly to allow us to optimize.
bq. Would WITH INSERTS ONLY mean to also restrict to primary-keys without
clustering-key?
The MV optimization is still useful without that restriction, and you get
partial benefits on the others depending on what kinds of read requests are
served. So IMO we shouldn't do this for a first cut.
> Append-only optimization
> ------------------------
>
> Key: CASSANDRA-9779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9779
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Jonathan Ellis
> Fix For: 3.x
>
>
> Many common workloads are append-only: that is, they insert new rows but do
> not update existing ones. However, Cassandra has no way to infer this and so
> it must treat all tables as if they may experience updates in the future.
> If we added syntax to tell Cassandra about this ({{WITH INSERTS ONLY}} for
> instance) then we could do a number of optimizations:
> - Compaction would only need to worry about defragmenting partitions, not
> rows. We could default to DTCS or similar.
> - CollationController could stop scanning sstables as soon as it finds a
> matching row
> - Most importantly, materialized views wouldn't need to worry about deleting
> prior values, which would eliminate the majority of the MV overhead
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
