Doris Profile Reader

Purpose

Use this skill to identify the real bottleneck in an Apache Doris query runtime profile. The core rule is to separate active work from dependency, queue, and backpressure waits before naming an operator as expensive. When the plan contains joins, also separate the immediate runtime bottleneck from the plan-shape cause, especially bad join order and runtime-filter direction.

Required Reading Order

1. Read references/reading-workflow.md for the analysis workflow and output contract.
2. Read references/counter-semantics.md for counter meaning and priority, especially wait counters.
3. Read references/operator-guide.md for the relevant operator family.
4. Read references/failure-patterns.md when the profile shows skew, bad join/distribution choices, weak pruning, sort/spill/resource pressure, external scans/catalogs, lifecycle waits, or when the user expects an issue-level root cause from profile-only evidence.
5. Read references/join-order-diagnosis.md when the profile or plan has multiple joins, a large hash/nested-loop build, a large scan that might have been pruned by a join, paired fast/slow plans, hints/reordered SQL, or a request about join shape/reorder.
6. Read references/runtime-filters.md when a profile or plan includes RuntimeFilterInfo, RF... <-, RF... ->, JRFs, WaitForRuntimeFilter, or AcquireRuntimeFilter.
7. Use references/source-profile-inventory.md as the source-backed operator/counter inventory. If a counter or operator is not in the narrative docs, do not ignore it; look it up in this inventory and classify it by the rules in counter-semantics.md.
8. Read references/solution-playbook.md when the user asks for a fix, workaround, mitigation, tuning, SQL rewrite, or when the requested output schema includes solution fields.
9. Read references/known-issues-solutions.md after the root-cause layer is established and a solution is requested. Use it as historical evidence, not as a replacement for profile diagnosis.

Non-Negotiable Interpretation Rules