You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Caleb William Rackliffe (JIRA)" <ji...@apache.org> on 2016/02/12 02:36:18 UTC

[jira] [Comment Edited] (CASSANDRA-9779) Append-only optimization

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

Caleb William Rackliffe edited comment on CASSANDRA-9779 at 2/12/16 1:35 AM:
-----------------------------------------------------------------------------

Would it make sense to reject (or at least allow rejection) for the case of an INSERT with only a partial row?


was (Author: maedhroz):
Would it make sense to reject (or at least allow rejection) for the case of an INSERT with only partial row?

> Append-only optimization
> ------------------------
>
>                 Key: CASSANDRA-9779
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9779
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: CQL
>            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)