yes, I will be re-inserting using the same keys. the reason I believe the tombstone behavior may be different is that (if I remember correctly) there is a "marked for delete" flag on the row in the SSTABLE. this could provide better performance than marking individual columns as deleted and having to skip them when slicing a row.
From: "R. Verlangen" <ro...@us2.nl<mailto:ro...@us2.nl>> Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Date: Tue, 14 Feb 2012 12:14:10 -0800 To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Subject: Re: deleting rows and tombstones Are you planning to insert rows with keys that existed before? If that's true, there will be no tombstones (as far as I understand Cassandra). It that's not, then you will get tombstones that might slow down the reads because they have to be skipped until the next compaction. 2012/2/14 Todd Burruss <bburr...@expedia.com<mailto:bburr...@expedia.com>> my design calls for deleting a row (by key, not individual columns) and re-inserting it a lot and I'm concerned about tombstone build up slowing down reads. I know if I delete a lot of individual columns the tombstones will build up and slow down reads until they are cleaned up, but not sure if the same holds for deleting the whole role. thoughts?
