@Rocky I have 2 questions 1. When I define a primary key table with live partitions to be 25, and a fake record generates future partitions, ahead of present time, does this evict older partitions? Or is partition expiry calculated from present time. 2. What user permissions exactly are required to create a materialized view?

Regarding your questions on StarRocks partition management and materialized view permissions: 1. Partition Eviction and Future Records In StarRocks, the eviction of older partitions is calculated based on the present (system) time, not based on the maximum partition date or future records. * Benchmark: The benchmark for the

partition_live_number

(in Expression Partitioning) or

dynamic_partition.start

(in Dynamic Partitioning) is the current date. * Behavior: If you set

partition_live_number = 25

, StarRocks calculates the retention window as

[Current Date - 25 units, Future]

. * Future Records: If a record generates a partition in the future, that partition will simply be created and retained. It does not push the benchmark forward or cause older partitions to be evicted earlier. For example, if today is January 30 and your retention is 25 days, the oldest retained partition is January 5. If you insert a "fake" record for December 2025, a future partition is created, but the eviction threshold remains January 5. 2. Required Permissions for Materialized Views The exact permissions required depend on the type of materialized view (MV) you are creating: For Asynchronous Materialized Views (most common): * Target Database:

CREATE MATERIALIZED VIEW

privilege on the database where the MV will be created. * Base Tables:

SELECT

privilege on all base tables, views, or other MVs referenced in the query definition. * Functions:

USAGE

privilege on any User-Defined Functions (UDFs) used in the query. For Synchronous Materialized Views (Rollup): * Database:

CREATE MATERIALIZED VIEW

privilege on the database where the base table resides (as synchronous MVs must exist within the same database as their base table). Additional Notes: * You can grant these using the following syntax:

sql
    GRANT CREATE MATERIALIZED VIEW ON DATABASE <db_name> TO USER <user>;
    GRANT SELECT ON TABLE <db_name>.<table_name> TO USER <user>;

* Refreshing an asynchronous MV typically requires the

REFRESH

privilege on the MV itself if triggered manually, though the initial creation and automated background refreshes are tied to the creator's or owner's permissions. References • using_starrocks/async_mv/Materialized_view.md • sql-reference/sql-statements/materialized_view/CREATE_MATERIALIZED_VIEW.md • using_starrocks/async_mv/troubleshooting_asynchronous_materialized_views.md