Hi Just to add to that, this is the way C* handles deletes. Cassandra creates delete markers called tombstones on delete requests. They are retained (even after compaction) for a period of time configured using gc_grace_seconds (default 10 days) to ensure that if a node was down when delete was issued, using this delete marker i.e. tombstone that node node can later be sychronised with delete information else the subsequent reads may lead to reading the deleted data i.e. ghost records getting reappeared. Here is a good link to explain more https://www.instaclustr.com/support/documentation/cluster-management/managing-tombstones/ <https://www.instaclustr.com/support/documentation/cluster-management/managing-tombstones/>
Alok Dwivedi Senior Consultant https://www.instaclustr.com/ > On 24 Apr 2019, at 20:20, onmstester onmstester <onmstes...@zoho.com.INVALID> > wrote: > > Found the answer: it would be deleted after gc_grace > Just decreased the gc_grace, run compact, and the "marked_deleted" partitions > purged from sstable > > Sent using Zoho Mail <https://www.zoho.com/mail/> > > > ---- On Wed, 24 Apr 2019 14:15:33 +0430 onmstester onmstester > <onmstes...@zoho.com.INVALID> wrote ---- > > Just deleted multiple partitions from one of my tables, dumping sstables > shows that the data successfully deleted, but the 'marked_deleted' rows for > each of partitions still exists on sstable and allocates storage. > Is there any way to get rid of these delete statements storage overhead > (everything be deleted after final compactions, even the delete statements)? > Sent using Zoho Mail <https://www.zoho.com/mail/> > > >
