Second, a followup question: So the row keys will be deleted after 1) the GC grace period expires, and 2) I do a compaction?
Automatic compaction will purge the tombstones. 

Third: Assuming the answer is yes, is there any way to manually force GC of the deleted keys without doing the full "GC shuffle" (setting the GC grace period artificially low, restarting, compacting, setting grace period back to normal, restarting)?
No. But you do not need to restart. gc_grace_seconds is set per CF and can be updated without a restart. 

Cheers

-----------------
Aaron Morton
Freelance Developer
@aaronmorton

On 1/02/2012, at 2:32 PM, Todd Fast wrote:

First, thanks! I'd read that before, but didn't associate doing a range scan with using the CLI, much less doing "select count(*)" in CQL. Now I know what to call the phenomenon.

Second, a followup question: So the row keys will be deleted after 1) the GC grace period expires, and 2) I do a compaction?

Third: Assuming the answer is yes, is there any way to manually force GC of the deleted keys without doing the full "GC shuffle" (setting the GC grace period artificially low, restarting, compacting, setting grace period back to normal, restarting)?

Todd

On 1/31/2012 5:03 PM, Benjamin Hawkes-Lewis wrote:
On Wed, Feb 1, 2012 at 12:58 AM, Todd Fast<todd@conga.com>  wrote:
I added a row with a single column to my 1.0.8 single-node cluster:

   RowKey: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
   =>  (column=test, value=hi, timestamp=...)

I immediately deleted the row using both the CLI and CQL:

   del Foo[lexicaluuid('aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa')];
   delete from Foo using consistency all where
KEY=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa

In either case, the column "test" is gone but the empty row key still
remains, and the row count reflects the presence of this phantom row.

I've tried nodetool compact/repair/flush/cleanup/scrub/etc. and nothing
removes the row key.
http://wiki.apache.org/cassandra/FAQ#range_ghosts

--
Benjamin Hawkes-Lewis