@Rocky explain me about plan mode 'auto' works plz.

In StarRocks,

plan_mode

is a session variable specifically used to control the metadata retrieval strategy for the Iceberg Catalog (introduced in v3.3.3). When

plan_mode

is set to

auto

(which is the default), StarRocks employs an Adaptive Metadata Retrieval Strategy. This means the system dynamically decides whether to process Iceberg metadata locally or in a distributed fashion to achieve the best performance. How

auto

Mode Works The

auto

mode balances two primary strategies based on the complexity of the query and the size of the metadata: 1. Local Plan (for small metadata): * If the query involves a small number of manifest files, StarRocks processes them on the FE. * It uses a caching mechanism for deserialized memory objects (like Avro files). This allows subsequent queries to bypass decompression and parsing, making the system highly responsive for small-scale queries. 2. Distributed Plan (for large metadata): * If the metadata volume is large (many manifest files), StarRocks distributes the tasks—such as reading, decompressing, and filtering those manifest files—across multiple BE (Backend) or CN (Compute Node) nodes. * This leverages parallel computing to eliminate single-point bottlenecks at the FE, significantly speeding up the planning phase for massive datasets. How it Decides In

auto

mode, StarRocks automatically evaluates several factors to pick the best strategy: * The number of manifest files required for the query. * Cluster resources: The number of available FE, BE, and CN nodes. * Hardware capacity: CPU core counts on the participating nodes. Other "Auto" Plan Settings While

plan_mode

is specifically for Iceberg, you may encounter other similar "auto" settings in StarRocks: *

new_planner_agg_stage = 0 (AUTO)

: Allows the optimizer to automatically choose between 1, 2, 3, or 4-stage aggregation based on cost. *

spill_mode = 'auto'

: Automatically triggers intermediate result spilling to disk when memory thresholds are reached. *

partial_update_mode = 'auto'

: Automatically determines whether to use

row

or

column

mode for partial updates in Primary Key tables. Recommendation: In most scenarios, keeping

plan_mode

at

auto

is recommended as it provides optimized "out-of-the-box" performance without manual tuning. References • data_source/catalog/iceberg/iceberg_catalog.md • sql-reference/System_variable.md

@Rocky when using stream_load api, i usally send request with fe pod 8030 port(with ingress). but there is no way to connect cn pod. what should i do?

The reason you cannot connect is that the Stream Load API involves an HTTP 307 Redirect. When you send a request to the FE (port 8030) via an Ingress, the FE picks a CN/BE node to handle the data and returns a

307 Temporary Redirect

response. This redirect contains the internal IP address (e.g.,

10.x.x.x:8040

) of the CN pod. Since your client is outside the cluster and connecting via Ingress, it cannot reach that internal pod IP, causing the load to fail. To fix this in a Kubernetes environment, you have two main options: 1. Use the "StarRocks FE Proxy" (Recommended) StarRocks provides a dedicated FE Proxy component (an Nginx-based proxy) specifically for this scenario. * How it works: The proxy sits between your client and the cluster. It receives the Stream Load request, forwards it to the FE, handles the 307 redirect internally within the Kubernetes network, and streams the data to the target CN. * Result: Your client only ever communicates with the Proxy's address. * Implementation: * If you use the StarRocks Helm Chart, enable it in your `values.yaml`:

yaml
        starrocksFeProxySpec:
          enabled: true
          service:
            type: LoadBalancer # or use an Ingress for this service

* Then, point your

curl

or client to the FE Proxy's IP/port (default

8080

) instead of the FE's 8030 port. 2. Map CN Pods to the Outside If you cannot use the FE Proxy, you must make the CN pods reachable from your client. * LoadBalancer per Pod: Not practical for many CNs. * NodePort: Expose the CN HTTP port (

8040

by default) via NodePort. However, the FE will still redirect to the internal IP unless you configure the CNs to advertise their external hostnames (using

brpc_address

or similar, which is complex in K8s). * Hosts file (Workaround): If the FE redirects to a hostname (e.g.,

starrocks-cn-0.starrocks-cn-search...

), you can manually add these hostnames to your client's

/etc/hosts

file, mapping them to the Ingress IP. Note that your Ingress must then be configured to route traffic based on these hostnames to the correct pods. Summary The most stable and standard way to handle Stream Load through an Ingress is to deploy the StarRocks FE Proxy. It eliminates the need for the client to have direct network visibility into the CN pods. References • quick_start/helm.md • loading/StreamLoad.md References • administration/management/FE_configuration.md • administration/management/BE_configuration.md