@Rocky why I can see running query in SHOW FULL PROCESSLIST and dont see in RUNNING QUERIES or in query detail api?

The discrepancy you are seeing between

SHOW FULL PROCESSLIST

and monitoring views like

SHOW RUNNING QUERIES

or the

Query Detail API

is usually due to the query's execution stage or configuration. Here are the primary reasons why a query appears in the process list but not in the other views: 1. Stage: Planning vs. Execution *

SHOW PROCESSLIST

: Tracks the connection thread on the FE. As soon as the FE receives a SQL command, it appears here with

Command=Query

. *

RUNNING QUERIES

/

current_queries

: These track queries in the execution engine. * Why the gap? If a query is stuck in the Parsing, Analyzing, or Planning phase (CBO optimization), or if it is waiting for a Metadata Lock, it will show in the process list but will not yet be registered as "Running" in the execution-level monitors because it hasn't reached the BE nodes yet. 2. Query Queue Configuration *

SHOW RUNNING QUERIES

: This command is specifically tied to the Query Queue feature (introduced in v3.1.4). * If the Query Queue is disabled (which is the default), this command may return empty or inconsistent results. * Query Type: The Query Queue usually only manages

SELECT

queries. DDL operations (like

ALTER TABLE

or

CREATE TABLE

) or certain DMLs will appear in

SHOW PROCESSLIST

but bypass the query queue and thus won't show in

SHOW RUNNING QUERIES

. 3. API Configuration (

Query Detail API

) * The Query Detail API (and the FE web UI query list) requires the FE configuration

enable_collect_query_detail_info

to be set to

true

. * If this is

false

, the FE does not cache query execution details in memory, and the API will not return information for running or finished queries. 4. Multi-FE Architecture *

SHOW PROCESSLIST

and

show proc '/current_queries'

are local to the FE you are currently connected to. * If you are using a multi-FE setup and want to see queries across the whole cluster, you should use

show proc '/global_current_queries'

(available in v3.4+) or check the specific FE where the query was initiated. 5. Permissions *

SHOW PROCESSLIST

only shows the current user's queries unless you are logged in as

root

or have

OPERATE

privileges. Ensure you are checking with a high-privilege account to see all system-wide running tasks. Summary Table View | Level | Scope | Common Reason for "Missing" Query

SHOW PROCESSLIST

| Connection | Local FE | Shows everything (even if stuck in planning).

show proc '/current_queries'

| Execution | Local FE | Query hasn't finished planning/optimization yet.

SHOW RUNNING QUERIES

| Queue | Global | Query Queue is not enabled or query is not a

SELECT

.

Query Detail API

| History/Profile | Global |

enable_collect_query_detail_info

is set to

false

. Recommendation: If a query is visible in

SHOW FULL PROCESSLIST

but not in the others, it is likely hanging during the FE optimization phase or waiting for a lock. You can try to

KILL <connection_id>

using the ID from the process list if it is blocking other tools cannot find it. References • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md • using_starrocks/running_queries.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md

@Rocky I have set to true -

enable_collect_query_detail_info

and may be that api also catches running queries (when they are in be) and not while query planing

Your observation is correct. The reason you see a query in

SHOW FULL PROCESSLIST

but not in

RUNNING QUERIES

or the

Query Detail API

is due to the query lifecycle and which part of the system is tracking it. 1.

SHOW FULL PROCESSLIST

(The Frontend Connection) This command tracks the MySQL connection thread on the FE. * When it appears: As soon as the FE receives the SQL string from the client. * What it includes: It shows the query even while it is in the Parsing, Analyzing, and Planning (CBO) stages. * Why it's there: If a query is stuck waiting for a Metadata Lock (e.g., another DDL is running) or if the CBO optimizer is taking a long time to generate a plan, it will be visible here with a state like

Query

. 2.

current_queries

and

Query Detail API

(The Execution Engine) These views track queries that have entered the Execution phase. * When it appears: After the FE has finished planning and is ready to distribute the query fragments to the BEs. * The Difference: These views rely on the

QeProcessor

and

QueryDetail

trackers. A query is typically registered here only when the plan is finalized. * Resource Metrics: Because these views show real-time metrics like

ScanBytes

,

MemoryUsage

, and

CPUTime

(which come from the BEs), a query that hasn't started execution on the BEs yet cannot provide this data and often won't appear in these lists. 3.

SHOW RUNNING QUERIES

(The Query Queue) This command specifically monitors the Query Queue (enabled via

enable_query_queue

). * When it appears: Only after the query has been planned and is attempting to acquire a "slot" to run. * Why it might be missing: If the query is still in the planning stage, it hasn't reached the queue yet. Also, if Query Queueing is disabled, this command may not show active queries consistently. Summary of Coverage Feature | Stage Captured | Primary Data Source

SHOW FULL PROCESSLIST

| All stages (from receipt to finish) | FE MySQL Connection Thread

show proc '/current_queries'

| Execution stage (BE-level) | FE Query Processor (BE feedback)

Query Detail API

| Execution stage |

QueryDetail

object (post-planning)

SHOW RUNNING QUERIES

| Queue & Execution | Query Queue Manager How to troubleshoot a "missing" but "running" query: If you see a query in

PROCESSLIST

with a high

Time

value but it's missing from the API: 1. Metadata Locks: Check

show proc '/catalog/db_name/metadata_lock'

(if applicable) to see if it's waiting for a lock. 2. Optimizer Time: The query might be extremely complex, causing the FE to spend a long time in the "Planning" phase. 3. FE Global vs Local: If you have multiple FEs,

current_queries

and

SHOW PROCESSLIST

only show queries on the local FE you are connected to. Use

show proc '/global_current_queries'

(v3.4+) to see execution across all FEs. Confirmed: Your hunch is correct—the API and

current_queries

generally catch queries once they move from the FE's internal planning to the actual execution/BE execution stage. References • using_starrocks/running_queries.md • administration/management/resource_management/query_queues.md • administration/management/monitoring/metrics.md • administration/management/monitor_manage_big_queries.md