[ 
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709261#comment-17709261
 ] 

Stefan Miklosovic commented on CASSANDRA-12937:
-----------------------------------------------

I think being consistent with CQL as well as be prepared for the future so we 
can specify any compressor without changing anything is more important. 

To summarise:
1) consistency with CQL
2) zero learning curve, a user just puts there what he is used to
3) any future in-built compressor supported out of the box so we do not need to 
think about it and we do not need to change other enums, switches etc to 
support that
4) custom compressor supported as well
5) any parameters possible to add
6) uses same code path for getting CompressorParams, no new classes and 
boiler-plate code necessary
7) One way of specifying in-built compressor as well as the custom one, we do 
not need to do any difference between them
8) We can configure every single parameter of a compressor, not only that 
helper creation functions offer us

I really think that all these points in total beats the argument that we need 
to have parameters in "so and so format". If we are transparent about the fact 
that what is used in CQL is accepted in sstable_compressor map, it is really a 
no-brainer.

[~mck] what do you think?

> Default setting (yaml) for SSTable compression
> ----------------------------------------------
>
>                 Key: CASSANDRA-12937
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Local/Config
>            Reporter: Michael Semb Wever
>            Assignee: Claude Warren
>            Priority: Low
>              Labels: AdventCalendar2021, lhf
>             Fix For: 5.x
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to 
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable 
> compression that new tables will inherit (instead of the defaults found in 
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly 
> compression (btrfs, zfs) or specific disk configurations or even specific C* 
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying 
> the field required for defining the default compression parameters. In 
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for 
> the default compression. This field should be initialized in 
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where 
> {{CompressionParams.DEFAULT}} was used the code should call 
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some 
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test 
> that the table schema use the new default when a new table is created (see 
> CreateTest for some example).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to