[
https://issues.apache.org/jira/browse/CASSANDRA-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126140#comment-13126140
]
Yang Yang edited comment on CASSANDRA-3354 at 10/12/11 8:51 PM:
----------------------------------------------------------------
btw why not remove the expired ttl directly in one shot?
if the expire happens right after the column goes into the largest
sstable (let's say 10GB), then the time window till the next compaction can be
very long, and all reads would have to scrape through a lot of dead columns
unnecessarily
was (Author: yangyangyyy):
btw why not remove the expired ttl directly in one shot?
> tombstone not removed after compaction
> --------------------------------------
>
> Key: CASSANDRA-3354
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3354
> Project: Cassandra
> Issue Type: Bug
> Reporter: Yang Yang
> Priority: Minor
>
> I set GC_grace to 2 hours, for testing.
> then I compacted the sstables using nodecmd,
> but the resulting sstables contained many Deletion records older than 2 hours
> "0000000000000d5e3263303666346331000000000000000100000000":
> [["00000132f8820139303030303030303030303030303030303030303030303030303030303030303030303263303666346332","4e95a659",1318429297125,"d"]],
> yyang@ip-10-71-86-162:~/src/svn/whisky$ perl -e 'print
> gmtime(1318429297)."\n" '
> Wed Oct 12 14:21:37 2011
> -rw-r--r-- 1 yyang yyang 381366163 2011-10-12 16:39
> /mnt/cass/lib/cassandra/data/testBudget_items/multi_click_filter-h-511-Data.db
> but it seems that after running a few more compactions, these records are gone
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
