[ https://issues.apache.org/jira/browse/CASSANDRA-18533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779554#comment-17779554 ]
Maxwell Guo edited comment on CASSANDRA-18533 at 11/2/23 3:18 PM: ------------------------------------------------------------------ [~blambov]Hi, I have some questions here. 1.we are going to put the format-specific options into the [option map|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/AbstractSSTableFormat.java#L27] here , am I right ? 2.it seems key_cache_size, key_cache_keys_to_save, key_cache_save_period, are not sstable level but just for key cache which is db level, should I remove them? 3.I am a little confusing now for table level configuration in CASSANDRA-18534 and options here. if we are going to define sstable option like [this |https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1029],then we may mix the table level options in CASSANDRA-18534 and the options here, what I am thinking is that YAML needs to define several types of configurations:(1) sstable option just for bti;(2) sstable option for big;(3) common option that can be used in bti and big; if we have other sstable format in the future ,we may need to expand this category. {code:java} sstable: selected_format:big (or some use custom type like big-fast) format.option: -common: row_index_granularity: xxx -big: bf_chance:xxxx -bti: xxxxxx -bti-fast: xxxx {code} where all the custom-type sstable format will inherit common's option values all will also have it's own custom option values, take their union as the final value. In this way, we can put all sstable configuration here, and CASSANDRA-18534 can also define the table's custom type of sstable format, through ddl using sstable_format = 'big', which can use the local yaml's value. was (Author: maxwellguo): [~blambov]Hi, I have some questions here. 1.we are going to put the format-specific options into the [option map|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/AbstractSSTableFormat.java#L27] here , am I right ? 2.it seems key_cache_size, key_cache_keys_to_save, key_cache_save_period, are not sstable level but just for key cache which is db level, should I remove them? 3.I am a little confusing now for table level configuration in CASSANDRA-18534 and options here. if we are going to define sstable option like [this |https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1029],then we may mix the table level options in CASSANDRA-18534 and the options here, feeling not clear as we mix the table level configuration together with those non-table level, should we separate them at yaml level, though the original yaml do not define a configuration as table level or not .if we define sstable format like this : {code:java} sstable: selected_format: big format.options: - bit-fast: row_index_granularity: 1kiB bloom_filter_fp_chance: 0.01 - big-small: row_index_granularity: 1kiB bloom_filter_fp_chance: 0.01 {code} what about change to {code:java} sstable: selected_format: big format.options: - bit-fast: row_index_granularity: 1kiB table-level: bloom_filter_fp_chance: 0.01 {code} {code} > Move format-specific sstable options into the format configuration > ------------------------------------------------------------------ > > Key: CASSANDRA-18533 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18533 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema, Local/SSTable > Reporter: Branimir Lambov > Assignee: Maxwell Guo > Priority: Normal > Fix For: 5.x > > > This mainly concerns cassandra yaml settings: > - {{column_index_size}}, which should also be renamed to > {{row_index_granularity}} > - {{column_index_cache_size}} > - {{index_summary_capacity}} > - {{index_summary_resize_interval}} > and possibly > - {{key_cache_size}}, {{key_cache_keys_to_save}}, {{key_cache_save_period}}, > {{key_cache_migrate_during_compaction}} > - {{sstable_preemptive_open_interval}} > Existing settings should be deprecated but still picked up if defined. > At this point we will not consider table-level options that make better sense > as format parameters ({{min/max_index_interval}}, {{bloom_filter_fp_chance}}, > {{crc_check_chance}} and possibly {{compression}}), because we do not yet > support per-table format selection/configuration. -- 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