Not any faster, as you'll still have to wait for all the SSTables to age off, as a partition level tombstone will simply go to a new SSTable and likely will not be compacted with the old SSTables.
On Tue, 25 Sep 2018 at 17:03, Martin Mačura <m.mac...@gmail.com> wrote: > Most partitions in our dataset span one or two SSTables at most. But > there might be a few that span hundreds of SSTables. If I located and > deleted them (partition-level tombstone), would this fix the issue? > > Thanks, > > Martin > On Mon, Sep 24, 2018 at 1:08 PM Jeff Jirsa <jji...@gmail.com> wrote: > > > > > > > > > > On Sep 24, 2018, at 3:47 AM, Oleksandr Shulgin < > oleksandr.shul...@zalando.de> wrote: > > > > On Mon, Sep 24, 2018 at 10:50 AM Jeff Jirsa <jji...@gmail.com> wrote: > >> > >> Do your partitions span time windows? > > > > > > Yes. > > > > > > The data structure used to know if data needs to be streamed (the merkle > tree) is only granular to - at best - a token, so even with subrange repair > if a byte is off, it’ll stream the whole partition, including parts of old > repaired sstables > > > > Incremental repair is smart enough not to diff or stream already > repaired data, the but the matrix of which versions allow subrange AND > incremental repair isn’t something I’ve memorized (I know it behaves the > way you’d hope in trunk/4.0 after Cassandra-9143) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >
