Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4F183F9FF for ; Wed, 21 Aug 2013 18:09:54 +0000 (UTC) Received: (qmail 9226 invoked by uid 500); 21 Aug 2013 18:09:51 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 8963 invoked by uid 500); 21 Aug 2013 18:09:47 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 8955 invoked by uid 99); 21 Aug 2013 18:09:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Aug 2013 18:09:46 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [163.231.6.26] (HELO mailout2-trp.thomsonreuters.com) (163.231.6.26) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Aug 2013 18:09:38 +0000 Received: from trpusmneagrly02.int.westgroup.com (relay2 [163.231.22.113]) by mailout2-trp.thomsonreuters.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r7LI9GKP031083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Aug 2013 18:09:16 GMT Received: from EAGE-ERFPHUB12.ERF.thomson.com (EAGE-ERFPHUB12.erf.thomson.com [10.220.31.97]) by trpusmneagrly02.int.westgroup.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r7LI9GIj015230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 21 Aug 2013 18:09:16 GMT Received: from C111MVNHHUB16.ERF.thomson.com (163.231.29.140) by EAGE-ERFPHUB12.ERF.thomson.com (10.220.31.97) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 21 Aug 2013 13:09:15 -0500 Received: from UK2P-ERFMHUB01.ERF.thomson.com (10.29.4.12) by C111MVNHHUB16.ERF.thomson.com (163.231.29.140) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 21 Aug 2013 13:09:15 -0500 Received: from UK2P-ERFMMBX15.ERF.thomson.com ([fe80::1876:69be:6909:9041]) by UK2P-ERFMHUB01.ERF.thomson.com ([::1]) with mapi id 14.02.0342.003; Wed, 21 Aug 2013 18:09:13 +0000 From: To: Subject: RE: Automatic tombstone compaction Thread-Topic: Automatic tombstone compaction Thread-Index: Ac6eeNlKMgRvZ5PvT+O0Ih7RracObQAAUYWAAAA6o3AAAdjkAAAE81iAAACunAk= Date: Wed, 21 Aug 2013 18:09:12 +0000 Message-ID: <8DB9FC6F3E04544EB041210DCCB1E1710E3D5CF1@UK2P-ERFMMBX15.ERF.thomson.com> References: <8DB9FC6F3E04544EB041210DCCB1E1710E3D5AFE@UK2P-ERFMMBX15.ERF.thomson.com> <8DB9FC6F3E04544EB041210DCCB1E1710E3D5B29@UK2P-ERFMMBX15.ERF.thomson.com> , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.231.31.66] Content-Type: multipart/alternative; boundary="_000_8DB9FC6F3E04544EB041210DCCB1E1710E3D5CF1UK2PERFMMBX15ER_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.2.0.3176-7.000.1014-20092.005 X-TM-AS-Result: No--15.142400-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-Virus-Checked: Checked by ClamAV on apache.org --_000_8DB9FC6F3E04544EB041210DCCB1E1710E3D5CF1UK2PERFMMBX15ER_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, these tables are somewhat similar to a 'cache' - we insert rows, then= leave them for a week using TTL (usually untouched, read only), and then w= e need to compact them away. If I understand correctly, they should not be = affected by the below issue... The question is rather if the setup is correct - i.e the ALTER statement I = quoted below? Also, I the docs were not clear to me - is automatic tombstone compaction '= on' by default (even if the sstables have been migrated from an older versi= on)? Or do I need to alter the columnfamily (like I did) to turn it on? ________________________________ From: Robert Coli [rcoli@eventbrite.com] Sent: Wednesday, August 21, 2013 7:45 PM To: user@cassandra.apache.org Subject: Re: Automatic tombstone compaction On Wed, Aug 21, 2013 at 8:23 AM, Yuki Morishita > wrote: If there are rows with the same key in other SSTables, that rows won't be deleted. Tombstone compaction make guess if it can actually drop "safely" by scanning overlap with other SSTables. Background @ : https://issues.apache.org/jira/browse/CASSANDRA-1074 =3DRob --_000_8DB9FC6F3E04544EB041210DCCB1E1710E3D5CF1UK2PERFMMBX15ER_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Well, these tables are somewhat similar to a 'cache' - we insert rows,= then leave them for a week using TTL (usually untouched, read only), and t= hen we need to compact them away. If I understand correctly, they should no= t be affected by the below issue...
The question is rather if the setup is correct - i.e the ALTER stateme= nt I quoted below?

Also, I the docs were not clear to me - is automatic tombstone compact= ion 'on' by default (even if the sstables have been migrated from an older = version)? Or do I need to alter the columnfamily (like I did) to turn it on= ?

From: Robert Coli [rcoli@eventbrite.com]<= br> Sent: Wednesday, August 21, 2013 7:45 PM
To: user@cassandra.apache.org
Subject: Re: Automatic tombstone compaction

On Wed, Aug 21, 2013 at 8:23 AM, Yuki Morishita <mor.yu= ki@gmail.com> wrote:
If there are rows with the same key in other SSTables, that rows won't
be deleted.
Tombstone compaction make guess if it can actually drop "safely" = by
scanning overlap with other SSTables.

Background @ :


=3DRob
 
--_000_8DB9FC6F3E04544EB041210DCCB1E1710E3D5CF1UK2PERFMMBX15ER_--