On Wed, Jan 19, 2011 at 11:52 AM, Jonathan Ellis wrote:
> On Wed, Jan 19, 2011 at 6:41 AM, Germán Kondolf
> 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 comma
On Wed, Jan 19, 2011 at 6:41 AM, Germán Kondolf
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
On Wed, Jan 19, 2011 at 8:41 PM, Germán Kondolf wrote:
> On Wed, Jan 19, 2011 at 12:59 AM, Zhu Han wrote:
> >
> >
> > On Wed, Jan 19, 2011 at 11:35 AM, Germán Kondolf <
> german.kond...@gmail.com>
> > wrote:
> >>
> >> Yes, that's what I meant, but correct me if I'm wrong, when a deletion
> >> com
On Wed, Jan 19, 2011 at 12:59 AM, Zhu Han wrote:
>
>
> On Wed, Jan 19, 2011 at 11:35 AM, Germán Kondolf
> wrote:
>>
>> Yes, that's what I meant, but correct me if I'm wrong, when a deletion
>> comes after another deletion for the same row or column will the gc-before
>> count against the last one
On Wed, Jan 19, 2011 at 11:35 AM, Germán Kondolf
wrote:
> Yes, that's what I meant, but correct me if I'm wrong, when a deletion
> comes after another deletion for the same row or column will the gc-before
> count against the last one, isn't it?
>
> IIRC, after compaction. even if the row key is n
Yes, that's what I meant, but correct me if I'm wrong, when a deletion comes
after another deletion for the same row or column will the gc-before count
against the last one, isn't it?
Maybe knowing that all the subsequent versions of a deletion are deletions too,
it could take the first timesta
I'm not clear here. Are you worried about the later inserted tombstone
prevents the whole row from being reclaimed and the storage space can not be
freed?
To my knowledge, after major compaction, only the row key and tombstone
are kept. Is it a big deal?
best regards,
hanzhu
On Tue, Jan 18,
If the tombstone is older than the row or column inserted later, is the
tombstone skipped entirely after compaction?
best regards,
hanzhu
On Wed, Jan 19, 2011 at 11:16 AM, Jonathan Ellis wrote:
> If you mean that multiple tombstones for the same row or column should
> be merged into a single o
If you mean that multiple tombstones for the same row or column should
be merged into a single one at compaction time, then yes, that is what
happens.
On Tue, Jan 18, 2011 at 7:53 PM, Germán Kondolf
wrote:
> Maybe it could be taken into account when the compaction is executed,
> if I only have a
Maybe it could be taken into account when the compaction is executed,
if I only have a consecutive list of uninterrupted tombstones it could
only care about the first. It sounds like the-way-it-should-be, maybe
as a part of the "row-reduce" process.
Is it feasible? Looking into the CASSANDRA-1074
Sylvain,
Just to check my knowledge. Is this only the case if the delete is sent without
a super column or predicate? What about a delete for a specific column that did
not exist?
Thanks
Aaron
On 19/01/2011, at 2:58 AM, David Boxenhorn wrote:
> Thanks.
>
> On Tue, Jan 18, 2011 at 3:55 PM,
Thanks.
On Tue, Jan 18, 2011 at 3:55 PM, Sylvain Lebresne wrote:
> On Tue, Jan 18, 2011 at 2:41 PM, David Boxenhorn
> wrote:
> > Thanks, Aaron, but I'm not 100% clear.
> >
> > My situation is this: My use case spins off rows (not columns) that I no
> > longer need and want to delete. It is possi
On Tue, Jan 18, 2011 at 2:41 PM, David Boxenhorn wrote:
> Thanks, Aaron, but I'm not 100% clear.
>
> My situation is this: My use case spins off rows (not columns) that I no
> longer need and want to delete. It is possible that these rows were never
> created in the first place, or were already de
Thanks, Aaron, but I'm not 100% clear.
My situation is this: My use case spins off rows (not columns) that I no
longer need and want to delete. It is possible that these rows were never
created in the first place, or were already deleted. This is a very large
cleanup task that normally deletes a l
AFAIK that's not necessary, there is no need to worry about previous deletes.
You can delete stuff that does not even exist, neither batch_mutate or remove
are going to throw an error.
All the columns that were (roughly speaking) present at your first deletion
will be available for GC at the en
Thanks. In other words, before I delete something, I should check to see
whether it exists as a live row in the first place.
On Tue, Jan 18, 2011 at 9:24 AM, Ryan King wrote:
> On Sun, Jan 16, 2011 at 6:53 AM, David Boxenhorn
> wrote:
> > If I delete a row, and later on delete it again, before
On Sun, Jan 16, 2011 at 6:53 AM, David Boxenhorn wrote:
> If I delete a row, and later on delete it again, before GCGraceSeconds has
> elapsed, does the tombstone live longer?
Each delete is a new tombstone, which should answer your question.
-ryan
> In other words, if I have the following scen
If I delete a row, and later on delete it again, before GCGraceSeconds has
elapsed, does the tombstone live longer?
In other words, if I have the following scenario:
GCGraceSeconds = 10 days
On day 1 I delete a row
On day 5 I delete the row again
Will the tombstone be removed on day 10 or day 15
18 matches
Mail list logo
