There are some arguments to be made that the flush should consider compaction strategy - would allow a bug flush to respect LCS filesizes or break into smaller pieces to try to minimize range overlaps going from l0 into l1, for example.
I have no idea how much work would be involved, but may be worthwhile. -- Jeff Jirsa > On Feb 20, 2018, at 1:26 PM, Jon Haddad <j...@jonhaddad.com> wrote: > > The file format is independent from compaction. A compaction strategy only > selects sstables to be compacted, that’s it’s only job. It could have side > effects, like generating other files, but any decent compaction strategy will > account for the fact that those other files don’t exist. > > I wrote a blog post a few months ago going over some of the nuance of > compaction you mind find informative: > http://thelastpickle.com/blog/2017/03/16/compaction-nuance.html > > This is also the wrong mailing list, please direct future user questions to > the user list. The dev list is for development of Cassandra itself. > > Jon > >> On Feb 20, 2018, at 1:10 PM, Carl Mueller <carl.muel...@smartthings.com> >> wrote: >> >> When memtables/CommitLogs are flushed to disk/sstable, does the sstable go >> through sstable organization specific to each compaction strategy, or is >> the sstable creation the same for all compactionstrats and it is up to the >> compaction strategy to recompact the sstable if desired? >
