@Rocky when I create materialized view which is refreshed in every 1hour and I use user USER1 this view will be refreshed via that user and its resource group? so creator is the refresher?

Yes, in StarRocks, the identity used for the background refresh of an asynchronous materialized view is the user who created it (or the owner). Here is how the refresh identity and resource management work: 1. Refresher Identity The background refresh task (which appears as an

INSERT OVERWRITE

in the audit logs) runs under the identity of the creator. This means: * The refresh operation will check for the creator's privileges (e.g.,

SELECT

permissions on the base tables). * The

user

field in the audit log for these tasks will show

USER1

. 2. Resource Group Selection Where the refresh task actually "lands" for resource consumption depends on how you have configured your resource groups: * Explicit MV Property (Recommended): If you specify the

resource_group

property when creating the MV, the refresh task will always use that group, regardless of the user's personal resource group settings.

sql
    CREATE MATERIALIZED VIEW my_mv
    REFRESH ASYNC EVERY (INTERVAL 1 HOUR)
    PROPERTIES (
        "resource_group" = "dedicated_mv_rg"
    )
    AS SELECT ...;

* User-Bound Resource Group: If you have created a resource group and bound it to

USER1

(e.g.,

CREATE RESOURCE GROUP ... TO (user='USER1')

), and you did not specify a

resource_group

in the MV properties, the refresh task will generally follow the user's bound resource group rules. * Default System Group: If no specific property is set on the MV and no specific user-binding exists that catches the task, the system assigns it to the built-in resource group named

default_mv_wg

. This group is specifically designed to isolate MV refreshes so they don't impact your interactive queries. Summary * Is the creator the refresher? Yes, the refresh task inherits the creator's identity. * Will it use the user's resource group? Yes, unless you explicitly specify a different

resource_group

in the MV's

PROPERTIES

or if the system defaults it to

default_mv_wg

to protect your cluster's performance. Best Practice Tip: To ensure your background refreshes don't starve your dashboard queries, it is highly recommended to either: 1. Configure the

default_mv_wg

limits (CPU/Memory). 2. Explicitly set a

"resource_group" = "your_custom_rg"

in the MV properties. References • using_starrocks/async_mv/materialized_view_task_run_details.md