Sorry, to be clear - I'm +1 on changing the configuration default, but I think changing the compression in memory representations warrants further discussion and investigation before making a case for or against it yet. An optimization that reduces in memory cost by over 50% sounds pretty good and we never were really explicit that those sort of optimizations would be excluded after our feature freeze. I don't think they should necessarily be excluded at this time, but it depends on the size and risk of the patch.
On Sat, Oct 20, 2018 at 8:38 AM Jonathan Haddad <j...@jonhaddad.com> wrote: > I think we should try to do the right thing for the most people that we > can. The number of folks impacted by 64KB is huge. I've worked on a lot > of clusters created by a lot of different teams, going from brand new to > pretty damn knowledgeable. I can't think of a single time over the last 2 > years that I've seen a cluster use non-default settings for compression. > With only a handful of exceptions, I've lowered the chunk size considerably > (usually to 4 or 8K) and the impact has always been very noticeable, > frequently resulting in hardware reduction and cost savings. Of all the > poorly chosen defaults we have, this is one of the biggest offenders that I > see. There's a good reason ScyllaDB claims they're so much faster than > Cassandra - we ship a DB that performs poorly for 90+% of teams because we > ship for a specific use case, not a general one (time series on memory > constrained boxes being the specific use case) > > This doesn't impact existing tables, just new ones. More and more teams > are using Cassandra as a general purpose database, we should acknowledge > that adjusting our defaults accordingly. Yes, we use a little bit more > memory on new tables if we just change this setting, and what we get out of > it is a massive performance win. > > I'm +1 on the change as well. > > > > On Sat, Oct 20, 2018 at 4:21 AM Sankalp Kohli <kohlisank...@gmail.com> > wrote: > >> (We should definitely harden the definition for freeze in a separate >> thread) >> >> My thinking is that this is the best time to do this change as we have >> not even cut alpha or beta. All the people involved in the test will >> definitely be testing it again when we have these releases. >> >> > On Oct 19, 2018, at 8:00 AM, Michael Shuler <mich...@pbandjelly.org> >> wrote: >> > >> >> On 10/19/18 9:16 AM, Joshua McKenzie wrote: >> >> >> >> At the risk of hijacking this thread, when are we going to transition >> from >> >> "no new features, change whatever else you want including refactoring >> and >> >> changing years-old defaults" to "ok, we think we have something that's >> >> stable, time to start testing"? >> > >> > Creating a cassandra-4.0 branch would allow trunk to, for instance, get >> > a default config value change commit and get more testing. We might >> > forget again, from what I understand of Benedict's last comment :) >> > >> > -- >> > Michael >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> > For additional commands, e-mail: dev-h...@cassandra.apache.org >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> > > -- > Jon Haddad > http://www.rustyrazorblade.com > twitter: rustyrazorblade > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
