Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 1506 invoked from network); 18 Jun 2010 21:09:48 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 18 Jun 2010 21:09:48 -0000 Received: (qmail 96871 invoked by uid 500); 18 Jun 2010 21:09:47 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 96826 invoked by uid 500); 18 Jun 2010 21:09:46 -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 96816 invoked by uid 99); 18 Jun 2010 21:09:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Jun 2010 21:09:46 +0000 X-ASF-Spam-Status: No, hits=-0.8 required=10.0 tests=AWL,HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [216.82.254.3] (HELO mail172.messagelabs.com) (216.82.254.3) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 18 Jun 2010 21:09:40 +0000 X-VirusChecked: Checked X-Env-Sender: pstanhope@wimba.com X-Msg-Ref: server-3.tower-172.messagelabs.com!1276895359!50334385!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [64.1.25.213] Received: (qmail 16902 invoked from network); 18 Jun 2010 21:09:19 -0000 Received: from 64.1.25.213.ptr.us.xo.net (HELO mail.wimba.com) (64.1.25.213) by server-3.tower-172.messagelabs.com with SMTP; 18 Jun 2010 21:09:19 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.wimba.com (Postfix) with ESMTP id 5C4ADB3828E for ; Fri, 18 Jun 2010 17:09:19 -0400 (EDT) Received: from mail.wimba.com ([127.0.0.1]) by localhost (mail.wimba.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdQ4tdUKCNIb for ; Fri, 18 Jun 2010 17:09:14 -0400 (EDT) Received: from 103.sub-75-247-197.myvzw.com (103.sub-75-247-197.myvzw.com [75.247.197.103]) by mail.wimba.com (Postfix) with ESMTP id C7211B38091 for ; Fri, 18 Jun 2010 17:09:13 -0400 (EDT) From: Phil Stanhope Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-13-87923586 Subject: Re: what is the best way to truncate a column family Date: Fri, 18 Jun 2010 17:09:10 -0400 In-Reply-To: To: user@cassandra.apache.org References: <435C011F-9E17-4DB0-856C-F8D6C3293F02@wimba.com> Message-Id: X-Mailer: Apple Mail (2.1078) --Apple-Mail-13-87923586 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am happy with this restriction on truncate operation for 0.7. Thanks = for the quick response. -phil On Jun 18, 2010, at 4:57 PM, Ran Tavory wrote: > it will be immediate.=20 > But it will fail if not all hosts in the cluster are up, this is the = tradeoff. We regard the truncate operation an admin api so I think it's = a fair tradeoff.=20 >=20 > On Fri, Jun 18, 2010 at 11:50 PM, Phil Stanhope = wrote: > In 0.6.x the iterating approach works ... but you need to flush and = compact (after GCGraceSeconds) in order to NOT see the keys in the CF. >=20 > Will the behavior of the truncate method in 0.7 require flush/compact = as well? Or will it be immediate? >=20 > -phil >=20 > On Jun 18, 2010, at 1:29 PM, Benjamin Black wrote: >=20 > > In 0.6 your only option with those constraints is to iterate over = the > > entire CF and deleting row by row. This requires you are either = using > > OPP or have an index that covers all keys in the CF. 0.7 adds the > > ability to truncate a CF (deleting all its rows) through the API. > > > > On Fri, Jun 18, 2010 at 10:24 AM, Claire Chang > > wrote: > >> programmatically w/o bringing the servers down. > >> > >> thanks, > >> claire > >> >=20 >=20 --Apple-Mail-13-87923586 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I am happy with this restriction on truncate operation for 0.7. Thanks for the quick response.

-phil

On Jun 18, 2010, at 4:57 PM, Ran Tavory wrote:

it will be immediate. 
But it will fail if not all hosts in the cluster are up, this is the tradeoff. We regard the truncate operation an admin api so I think it's a fair tradeoff. 

On Fri, Jun 18, 2010 at 11:50 PM, Phil Stanhope <pstanhope@wimba.com> wrote:
In 0.6.x the iterating approach works ... but you need to flush and compact (after GCGraceSeconds) in order to NOT see the keys in the CF.

Will the behavior of the truncate method in 0.7 require flush/compact as well? Or will it be immediate?

-phil

On Jun 18, 2010, at 1:29 PM, Benjamin Black wrote:

> In 0.6 your only option with those constraints is to iterate over the
> entire CF and deleting row by row.  This requires you are either using
> OPP or have an index that covers all keys in the CF.  0.7 adds the
> ability to truncate a CF (deleting all its rows) through the API.
>
> On Fri, Jun 18, 2010 at 10:24 AM, Claire Chang
> <claire@merchantcircle.com> wrote:
>> programmatically w/o bringing the servers down.
>>
>> thanks,
>> claire
>>



--Apple-Mail-13-87923586--