The text I posted above is directly from the yaml. Is it intended that
"sstable:" is to be first segment of the yaml key for
"default_compaction"? If so, it won't because column_index_cache starts in
the first column.
I am happy to move the new configuration section, but I don't follow how
this
Only indented items below "sstable" belong to "sstable". It is commented
out by default to make it clear that it is not required and the default
values apply.
There are a number of sstable parameters which are historically spread
across the yaml with no structure. The point is that we should not a
Jacek,
I am a bit confused here. I find a key for "sstable" in the yaml but it is
commented out by default. There are a number of options under it that are
commented out and then one that is not and then the "default_compaction"
section, which I assume is supposed to apply to the "sstable" secti
Compression params for sstables should be under the "sstable" key.
- - -- --- - -
Jacek Lewandowski
wt., 19 mar 2024 o 13:10 Ekaterina Dimitrova
napisał(a):
> Any new settings are expected to be added in the new format
>
> On Tue, 19 Mar 2024 at 5:52, Bowen Song via d
We can not support both the "rule" that new settings have the new format,
and the design goal that the CQL statement format be accepted.
We came to a compromise.
We introduced the new chunk_length parameter that requires a DataStorageSpec
We reused the CQL chunk_length_in_kb parameter to accept th
Any new settings are expected to be added in the new format
On Tue, 19 Mar 2024 at 5:52, Bowen Song via dev
wrote:
> I believe the `foobar_in_kb: 123` format in the cassandra.yaml file is
> deprecated, and the new format is `foobar: 123KiB`. Is there a need to
> introduce new settings entries wi
The earlier request was to be able to take the CQL statement and (with very
little modification) use it in the YAML. While I agree that introducing
the new setting to remove it later is a bit wonky, it is necessary to
support the current CQL statement. Unless the CQL statement has changed
already
I believe the `foobar_in_kb: 123` format in the cassandra.yaml file is
deprecated, and the new format is `foobar: 123KiB`. Is there a need to
introduce new settings entries with the deprecated format only to be
removed at a later version?
On 18/03/2024 14:39, Claude Warren, Jr via dev wrote:
After much work by several people, I have pulled together the changes to
define the default compression in the cassandra.yaml file and have created
a pull request [1].
If you are interested this in topic, please take a look at the changes and
give at least a cursory review.
[1] https://github.co
