On Wed, Jan 19, 2011 at 11:52 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > On Wed, Jan 19, 2011 at 6:41 AM, Germán Kondolf > <german.kond...@gmail.com> wrote: >> As the original example depicted clearly: >> day 1 -> insert Row1.Col1 >> day 2 -> delete Row1.Col1 >> day 11 (before gc-grace-seconds) -> delete Row1.Col1 >> >> In the last command I've extended the life of a tombstone, maybe the >> check before the deletion could have a performance impact in the >> process, so I think it might be handled server-side instead of >> client-side. > > It has performance implications no matter where you do it, which is > why we're not going to do it on the server. :) > > "Writes [or deletes] don't cause reads" is a basic design decision. > This is a much bigger win than the very narrow corner case of being > able to remove a tombstone marker a little earlier. >
I totally agree on that, I'll never propose a read before a write server-side, my bad, I didn't make that clear. The idea is that in the reduce process during a compaction we could change the logic to take the oldest expiration time instead of the youngest, I should take a look to the code to see if it's feasible. A workaround just by configuration is to reduce the gc-grace-seconds enough to avoid this undesired "tombstone-keep-alive". //GK http://twitter.com/germanklf http://code.google.com/p/seide/ > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com >
