fix: explain analyze m-cte should work

[dqhl76]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

fix: m-cte profiles miss

Before this PR, EXPLAIN ANALYZE could lose or mis-attach profile information for nested query executions.

The main problem was that profile collection used plan ids as if they were globally unique inside one QueryContext. However, nested executors, materialized CTE producer CTAS runs, and recursive CTE step pipelines each emit executor-local plan ids. As a result:

• profiles from different executions could collide or overwrite each other
• materialized CTE producer plans/profiles were not rendered with the outer explain result
• recursive CTE step profiles were not attached back under the recursive UnionAll scope

-[ EXPLAIN ]-----------------------------------
Sort(Single)
├── cpu time: 974.872µs
├── output rows: 5
├── output bytes: 88.00 B
├── output columns: [t1.a (#0), t1.cnt (#1), t1.total (#2)]
├── sort keys: [a ASC NULLS LAST]
├── estimated rows: 5.00
└── TableScan
    ├── cpu time: 453.624µs
    ├── wait time: 570.751µs
    ├── output rows: 5
    ├── output bytes: 88.00 B
    ├── bytes scanned: 88.00 B
    ├── read from remote: 159.00 B
    ├── runtime filter bloom time: 1.125µs
    ├── runtime filter inlist/min-max time: 541ns
    ├── table: default.default.t1
    ├── scan id: 0
    ├── output columns: [a (#0), cnt (#1), total (#2)]
    ├── read rows: 5
    ├── read size: < 1 KiB
    ├── partitions total: 1
    ├── partitions scanned: 1
    ├── pruning stats: [segments: <range pruning: 1 to 1 cost: 1 ms>, blocks: <range pruning: 1 to 1 cost: 1 ms>]
    ├── push downs: [filters: [], limit: NONE]
    └── estimated rows: 5.00
MaterializedCTE: t1
└── DistributedInsertSelect
    ├── cpu time: 1.615789ms
    ├── wait time: 7.808586ms
    └── EvalScalar
        ├── cpu time: 41.292µs
        ├── output rows: 5
        ├── output bytes: 90.00 B
        ├── output columns: [COUNT(*) (#2), SUM(number) (#3), a (#4)]
        ├── expressions: [group_item (#1)]
        ├── estimated rows: 33.33
        └── AggregateFinal
            ├── cpu time: 11.273494ms
            ├── wait time: 15.014122ms
            ├── output rows: 5
            ├── output bytes: 90.00 B
            ├── output columns: [COUNT(*) (#2), SUM(number) (#3), number % 5 (#1)]
            ├── group by: [number % 5]
            ├── aggregate functions: [count(), sum(number)]
            ├── estimated rows: 33.33
            └── AggregatePartial
                ├── cpu time: 143.958µs
                ├── output rows: 5
                ├── output bytes: 85.00 B
                ├── group by: [number % 5]
                ├── aggregate functions: [count(), sum(number)]
                ├── estimated rows: 33.33
                └── EvalScalar
                    ├── cpu time: 49.292µs
                    ├── output rows: 100
                    ├── output bytes: 900.00 B
                    ├── output columns: [numbers.number (#0), number % 5 (#1)]
                    ├── expressions: [numbers.number (#0) % 5]
                    ├── estimated rows: 100.00
                    └── TableScan
                        ├── cpu time: 20.5µs
                        ├── output rows: 100
                        ├── output bytes: 800.00 B
                        ├── bytes scanned: 800.00 B
                        ├── table: default.system.numbers
                        ├── scan id: 0
                        ├── output columns: [number (#0)]
                        ├── read rows: 100
                        ├── read size: < 1 KiB
                        ├── partitions total: 1
                        ├── partitions scanned: 1
                        ├── push downs: [filters: [], limit: NONE]
                        └── estimated rows: 100.00

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

---

This change is 

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8cb7795e96

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Restore distributed pipeline build for recursive CTE steps

Building recursive-step pipelines with PipelineBuilder::finalize(&plan) bypasses the distributed-plan path that build_query_pipeline_without_render_result_set previously handled. If the recursive branch contains Exchange nodes (common on cluster/warehouse deployments), this path no longer performs fragment/action setup and can fail when executing distributed recursive CTE queries. Please route this code back through the distributed-aware builder (or equivalent logic) while keeping the profile-scope guard.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Include captured CTE executions in graphical analyze profiles

execute_and_get_profiles now returns only get_query_profiles_for_execution(profile_execution_id), which excludes other execution namespaces such as materialized-CTE producer CTAS runs. Text explain output re-adds those via format_captured_cte_sections, but graphical output uses only this returned map, so EXPLAIN ANALYZE ... GRAPHICAL can silently miss materialized CTE producer profiles.

Useful? React with 👍 / 👎.