Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 75746 invoked from network); 12 Jul 2010 23:34:10 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 12 Jul 2010 23:34:10 -0000 Received: (qmail 64283 invoked by uid 500); 12 Jul 2010 23:34:08 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 64233 invoked by uid 500); 12 Jul 2010 23:34:08 -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 64225 invoked by uid 99); 12 Jul 2010 23:34:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Jul 2010 23:34:08 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bburruss@real.com designates 207.188.23.6 as permitted sender) Received: from [207.188.23.6] (HELO jor-el.real.com) (207.188.23.6) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Jul 2010 23:34:00 +0000 Received: from seacas01.corp.real.com ([::ffff:192.168.139.56]) (TLS: TLSv1/SSLv3,128bits,AES128-SHA) by jor-el.real.com with esmtp; Mon, 12 Jul 2010 16:33:39 -0700 id 000940B9.4C3BA653.0000263C Received: from seambx.corp.real.com ([fe80::2d15:fda7:b3b8:e268]) by seacas01.corp.real.com ([192.168.139.56]) with mapi; Mon, 12 Jul 2010 16:33:38 -0700 From: Todd Burruss To: "user@cassandra.apache.org" Date: Mon, 12 Jul 2010 16:33:38 -0700 Subject: GCGraceSeconds per ColumnFamily/Keyspace Thread-Topic: GCGraceSeconds per ColumnFamily/Keyspace Thread-Index: AQHLIhqnYcTZl8uuVkGzKfqOPTKcuw== Message-ID: <766B5A29D28DA442AB229AAEE2AFC44507F7A244D1@SEAMBX.corp.real.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org I have two CFs in my keyspace. one i care about allowing a good amount of = time for tombstones to propagate (GCGraceSeconds large) ... but the other i= couldn't care and in fact i want them gone ASAP so i don't iterate over th= em. has any thought been given to making this setting per Keyspace or per = ColumnFamily? my scenario is that i add columns to rows in one CF, UserData, with logging= data or activity, but we only want to keep, say 5000 columns per user. So= i also store the user's ID in another CF, PruneCollection, and periodicall= y iterate over it using the IDs found in PruneCollection to "prune" the col= umns in UserData - and then immediately delete the ID from PruneCollection.= if the code is adding, say 50 IDs per second to PruneCollection then the = number of deleted keys starts to build up, forcing my iterator to skip over= large amounts of deleted keys. With a small GCGraceSeconds these keys are= removed nicely, but i can't do that because it affects the tombstones in U= serData as well, which need to be propagated. thoughts?=