I think 16k is a better default, but it should only affect new tables. Whoever
changes it, please make sure you think about the upgrade path.
> On Oct 12, 2018, at 2:31 AM, Ben Bromhead wrote:
>
> This is something that's bugged me for ages, tbh the performance gain for
> most use cases fa
On Thu, Oct 11, 2018 at 4:31 PM Ben Bromhead wrote:
> This is something that's bugged me for ages, tbh the performance gain for
> most use cases far outweighs the increase in memory usage and I would even
> be in favor of changing the default now, optimizing the storage cost later
> (if it's foun
Recently I reached an inflection point where my annoyance of launching
clusters finally overcame my laziness. I wanted something similar to CCM,
so I wrote it.
The tool was designed for our usage at TLP, which usually means quickly
firing up clusters for running tests. It started out as some scr
This is something that's bugged me for ages, tbh the performance gain for
most use cases far outweighs the increase in memory usage and I would even
be in favor of changing the default now, optimizing the storage cost later
(if it's found to be worth it).
For some anecdotal evidence:
4kb is usuall
Hi,
This is regarding https://issues.apache.org/jira/browse/CASSANDRA-13241
This ticket has languished for a while. IMO it's too late in 4.0 to implement a
more memory efficient representation for compressed chunk offsets. However I
don't think we should put out another release with the current
