Support ALTER TABLE SET auto_flush_interval

[discord9]

What type of request is this?

Follow-up enhancement for table-level auto_flush_interval.

What subsystems are affected?

Distributed Cluster, Storage Engine, Table Engine, Frontend, Datanode

Background

PR #8357 added table-level auto_flush_interval support for the CREATE TABLE path:

CREATE TABLE t (
    ts TIMESTAMP TIME INDEX
) WITH ('auto_flush_interval' = '5m');

The PR description explicitly scoped the change to creation time and noted that ALTER TABLE support should follow later:

Scope: this PR covers setting the option at CREATE TABLE. Changing it via ALTER TABLE is a natural follow-up (a SetRegionOption::AutoFlushInterval variant + the apply path in handle_alter); happy to fold it in here if preferred.

Requested follow-up

Support changing the per-table auto flush interval on existing tables:

ALTER TABLE t SET 'auto_flush_interval' = '5m';

This is useful for old/existing tables after upgrade: users can opt in to the new per-table flush cadence without recreating the table.

Current behavior

The statement is currently rejected because the ALTER TABLE SET option plumbing does not include auto_flush_interval yet:

Error: 1004(InvalidArguments), Invalid set table option request: Invalid set region option request, key: auto_flush_interval, value: 5m

Relevant implementation areas:

• src/store-api/src/region_request.rs: add a SetRegionOption::AutoFlushInterval variant and parse/validate positive humantime durations.
• src/table/src/metadata.rs: persist the table option to TableOptions.extra_options.
• src/mito2/src/worker/handle_alter.rs: apply the new interval to the current region options, similar to other fast region options.

Version

Current main / development build after PR #8357.

[srivtx]

hey, I'd like to take this on. the outline matches what I had in mind — SetRegionOption::AutoFlushInterval following the Ttl variant shape, persist via TableOptions.extra_options, and apply in handle_alter_region_options_fast modeled on the Ttl arm.

one question before I dig in: should the variant be Option<Duration> (so ALTER TABLE ... SET auto_flush_interval = NULL clears the override and falls back to the global) or just a plain Duration (so once set it can only be changed to another value, not unset)? leaning toward the former for consistency with how Ttl works, but want to confirm.

also — do I need to touch any .proto files for this, or is the existing key/string flow enough? I see the Ttl and AppendMode variants already going through the gRPC layer, so I'm guessing no protos, but would rather ask than find out the hard way.

will write the apply logic + a sqlness test under tests/cases/standalone/common/ once you confirm. happy to start as a draft PR first if you want to see the direction before I commit to the proto/storage shape.

[evenyag]

Not sure if @raphaelroshan is working on this.