On Mon, Mar 30, 2009 at 5:19 PM, Jonathan Ellis <[email protected]> wrote: ... > Admittedly this is suboptimal compared to being able to GC immediately > but it has the virtue of being (a) easily implemented, (b) with no > extra components such as a coordination protocol, and (c) better than > not GCing tombstones at all (the other easy way to ensure > correctness).
I'm new here, so this may be a dumb objection, but: It also assumes that the number of un-GC'able SSTables is small (as compared to free disk space), right? If nodes A and B kept a (key, timestamp, tombstone) triple outside of the SSTable, then they could tell the client to delete C rather than repairing A/B, right? (Maybe this is what you meant by 'coordination protocol'?)
