[
https://issues.apache.org/jira/browse/CASSANDRA-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-9779:
----------------------------------
Comment: was deleted
(was: {quote}
I'm wondering if given DTCS and other optimization we have internally this
really bring that much to the table.
{quote}
I've been watching this ticket primarily because if 'append only' tables exist,
it should be possible to special case
{{CompactionController.getFullyExpiredSSTables}} so that DTCS/TWCS can drop
tables with timestamp overlaps (sstable expired blockers), which would be
significantly more efficient than trying to split out read-repaired cells
during compaction a la CASSANDRA-10496
)
> 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)
