@Rocky [ Q1. about

perfer_compute_node

system variable ] Hi, All! Among the system variables, there are

use_compute_nodes

and

prefer_compute_node

. Would it be beneficial to enable these options? Since the default is set to false, I’m wondering whether enabling them is generally effective in a shared-data architecture (using CN nodes).

Hi! I'm Rocky, and I'd be happy to help you with your question about these system variables! In StarRocks, the variables

prefer_compute_node

and

use_compute_nodes

are primarily used to control how the Frontend (FE) schedules query execution across different types of worker nodes. Here is a breakdown of how they behave and whether you should enable them based on your architecture: 1. What do these variables do? *

prefer_compute_node

: When set to

true

, the FE will prioritize distributing query execution plans to Compute Nodes (CN) rather than traditional Backends (BE). * Default:

false

(Historically, StarRocks preferred BEs to maintain data locality). *

use_compute_nodes

: This determines the maximum number of CN nodes the FE can use for a query. * Default:

-1

(which means use all available CN nodes). This variable is only effective if

prefer_compute_node

is set to

true

. 2. Is it beneficial for Shared-Data Architecture? In a Shared-data architecture (introduced in v3.0, where

run_mode = shared_data

), the worker nodes are registered as CN nodes by design. * In Version 3.2.7 and later: StarRocks introduced a newer variable called

computation_fragment_scheduling_policy

, which defaults to

compute_nodes_only

. In this case, the system already knows to use CNs for all computation fragments, so you generally do not need to manually enable

prefer_compute_node

. * In earlier v3.x versions: While the global default for

prefer_compute_node

is

false

, the FE in shared-data mode is optimized to use the available CNs for cloud-native tables. However, enabling

prefer_compute_node=true

can still be beneficial, especially if you are querying External Catalogs (like Hive or Iceberg) and want to ensure the compute is consistently distributed to your CN cluster. 3. When is it MOST effective to enable? Enabling these options is most critical in a Shared-nothing (classic) architecture where you have added extra CN nodes to your existing BE cluster to scale compute elastically. * Without it (

false

): The FE will try to run queries primarily on the BEs (where the data is stored) to avoid network overhead. The CNs might remain idle unless you are querying external data. * With it (

true

): The FE will offload computation to the CNs, which is exactly what you want when scaling compute independently of storage. Summary Recommendation * For Shared-Data (v3.0+): It is generally not necessary to change the default because the architecture is already built around CNs. If you are on v3.2.7+, the new scheduling policy handles this automatically. * For Shared-Nothing with added CNs: You should enable

prefer_compute_node = true

to ensure your CN nodes are actually being utilized for query processing. *

use_compute_nodes

: You can safely leave this at

-1

to ensure all your compute resources are available for use. If you are seeing that your CN nodes have low CPU usage while your FEs are busy, double-checking these variables is a good first step! Do you have a specific version of StarRocks you are currently running? References • quick_start/shared-data.md • deployment/shared_data/hdfs.md • introduction/Architecture.md • sql-reference/System_variable.md • deployment/shared_data/feature-support-shared-data.md