@Rocky can you change table cache properties after creation?

Whether you can change table cache properties after creation depends on the property and your StarRocks version. 1.

datacache.enable

(Local Disk Cache) * StarRocks v4.1 and later: Yes, you can dynamically enable or disable the data cache for cloud-native tables using the

ALTER TABLE

statement.

sql
    ALTER TABLE <table_name> SET ("datacache.enable" = "{true | false}");

* Versions prior to v4.1: This property generally cannot be modified after creation. It must be specified in the

PROPERTIES

clause during

CREATE TABLE

. 2.

datacache.partition_duration

(Hot Data TTL) * StarRocks v3.1 and later: This property (which defines how long data remains in the local cache) can be dynamically modified for cloud-native tables.

sql
    ALTER TABLE <table_name> SET ("datacache.partition_duration" = "1 MONTH");

_Note: In StarRocks v3.0, this property was named

storage_cache_ttl

._ 3.

file_bundling

(Shared-data Optimization) * StarRocks v4.0 and later: You can manually enable

file_bundling

for existing tables to reduce API costs in shared-data clusters.

sql
    ALTER TABLE <table_name> SET ("file_bundling" = "true");

4.

storage_volume

* No: The

storage_volume

property cannot be changed after a table is created. This property determines the physical location (e.g., S3 bucket/path) where the table data is stored. If you need to change the storage volume, you must recreate the table or use

INSERT INTO ... SELECT

to migrate the data. Summary Table Property | Modifiable? | Requirement

datacache.enable

| Yes (v4.1+) | Shared-data cluster

datacache.partition_duration

| Yes (v3.1+) | Shared-data cluster

file_bundling

| Yes (v4.0+) | Shared-data cluster

storage_volume

| No | Fixed at creation References • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md • sql-reference/sql-statements/cluster-management/storage_volume/ALTER_STORAGE_VOLUME.md • sql-reference/sql-statements/cluster-management/storage_volume/CREATE_STORAGE_VOLUME.md

@Rocky what is the default for

datacache.partition_duration

By default, if you do not specify

datacache.partition_duration

when creating a cloud-native (shared-data) table, all data is treated as hot data and there is no time-based expiration. Key Details: * Behavior: Without this property, data stays in the local cache indefinitely unless it is evicted to make room for newer data based on the cache's LRU (Least Recently Used) or SLRU (Segmented LRU) policy. * Older Versions (v3.0): In StarRocks v3.0, this property was named

storage_cache_ttl

. * Manual Setting: You can explicitly set it to a specific duration (e.g.,

"1 MONTH"

,

"7 DAY"

,

"12 HOUR"

) to ensure only data within that time window is eligible to be re-loaded into the cache if it was previously evicted. How to check the current value: You can verify the effective cache TTL for your table's partitions using the following command:

sql
SHOW PROC '/dbs/<db_id>/<table_id>/partitions';

Look for the

CacheTTL

column. A value of

0

or a very large number typically indicates that no specific duration has been set (i.e., "infinite"). References • deployment/shared_data/s3.md • deployment/shared_data/feature-support-shared-data.md • sql-reference/sql-statements/table_bucket_part_index/CREATE_TABLE.md References • administration/management/BE_configuration.md • using_starrocks/caching/block_cache.md • deployment/shared_data/feature-support-shared-data.md • administration/management/FE_configuration.md • using_starrocks/caching/query_cache.md • sql-reference/System_variable.md

@Rocky so to set it to the default, you put a value of

0

?

To set

datacache.partition_duration

back to its default behavior (where all data is treated as hot and eligible for caching), you typically do not use the value

0

. In StarRocks, a value of

0

in a duration string (like

"0 DAY"

) would logically mean that data becomes "cold" immediately after creation, which is the opposite of the default behavior. How to Revert to Default The default state for this property is "unspecified" or "null." To return to the state where all data is cached regardless of age, you have two options depending on your goal: 1. Set an Empty String (Recommended for "Unsetting"): In StarRocks, setting a table property to an empty string often acts as an "unset" command to return it to the system default.

sql
    ALTER TABLE <table_name> SET ("datacache.partition_duration" = "");

2. Set a Very Large Duration: If you want to ensure data is effectively never considered "cold" by time, you can set a very long duration.

sql
    ALTER TABLE <table_name> SET ("datacache.partition_duration" = "99 YEAR");

Why

0

is risky The property expects a string format like

<num> <UNIT>

(e.g.,

"7 DAY"

). * If you pass a literal

0

(not a string), the command may fail due to a type mismatch. * If you pass

"0 HOUR"

, the system may interpret this as a directive to never cache data (because it "expires" at 0 hours old), which would cause a significant performance drop as every query would hit remote storage. Summary of Default Behavior * Default: All data is hot. * Property value:

NULL

or not specified. * Effect: Data is only evicted from the cache based on the disk quota and the LRU (Least Recently Used) algorithm, not based on its age. References • sql-reference/sql-statements/table_bucket_part_index/CREATE_TABLE.md • deployment/shared_data/s3.md • using_starrocks/caching/block_cache.md • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md • administration/management/BE_configuration.md • faq/operation_maintenance_faq.md • deployment/shared_data/feature-support-shared-data.md • administration/management/FE_configuration.md • using_starrocks/caching/query_cache.md • sql-reference/System_variable.md References • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md • table_design/data_distribution/Temporary_partition.md