递归运行时调用指标 - #24565在 #24031 合并之后我认为对于下一轮递归 CTE 优化可能仍然需要有更好的依据。端到端的基准测试时间能告诉我一个查询是否有所改进但无法告诉我一个轮次epoch是主要消耗在调度、去重、键控状态维护、循环状态访问还是不变构建invariant build上。现有的递归PhysicalOperator日志包含有用的聚合计数但对于嵌套调用或区分主要执行阶段它无法可靠地回答这些问题。简而言之此 PR在现有的PhysicalOperator日志中为每个递归 CTE 状态提供一个稳定的调用身份invocation identity报告有界的每轮次分布和前沿容量指标归因于直接探测、键控状态维护、回退扫描fallback scan、最终排空final draining、去重、活跃递归管道、保留构建retained build和保留 CTE 物化在选择工作进程worker时区分递归扫描工作和直接键探测工作以及保持无日志记录no-logging的热路径不受指标时钟和原子更新的影响。调用和轮次证据嵌套递归 CTE 可以为同一个物理运算符创建和销毁多个运行时状态。一些缓存状态的生命周期也超过了最初描述它们的运算符数据。因此当创建一个启用日志记录的状态时我会快照物理运算符类型和参数并为每个物理递归运算符分配一个单调递增的调用 ID。RuntimeMetrics、EpochSummary和DistinctPromoted记录可以通过运算符标识例如表索引加上调用 ID 进行关联而无需保留对生命周期更短的运算符元数据的引用。EpochSummary对前沿行数、工作进程数、任务数和耗时使用固定的 2 的幂次直方图。它报告 p50 桶上界和确切的最大值而无需为每个轮次保留一个值。前沿部分还报告存储和分配字节-轮次byte-epochs以及峰值容量这使得窄但过度分配的递归变得可见。终端直方图桶直接覆盖完整的idx_t范围这捕获并修复了早期一个十进制位数与二进制位数混淆的错误。阶段指标特意明确说明了它们衡量什么领域证据直接 USING KEY 探测查找、键收集和负载最终化的工作进程时间探测行数、匹配数和部分索引链访问数键控状态哈希表提交、部分索引维护、回退循环扫描和最终状态排空的工作进程时间UNION DISTINCT分组工作进程时间以及候选数、插入数和重复拒绝数提升迁移promotion migration不计入候选总数递归管道活跃递归、保留连接/构建和保留物化 CTE 的PipelineExecutor::Execute工作进程时间以_work_ns结尾的字段是累积的工作进程时间而非关键路径上的墙上时钟时间因此并行值可能超过轮次的已用时间。直接探测和去重分组等运算符阶段发生在管道执行内部这些字段是嵌套的归因透镜attribution lens而不是应加到管道总数中的值。管道指标涵盖执行器工作并有意识地排除了准备/最终化阶段。现有的RuntimeMetrics总数对于轮次计数、调度器输入、接收器锁等待/工作、状态行数、保留构建计数和保留 CTE 重用仍然有用。我还纠正了PhysicalRecursiveCTEKeyJoin的递归工作发现。直接探测不再伪装成全循环状态扫描。递归探测输入已经由它们可见的递归扫描表示独立的探测输入为工作进程选择贡献估计的数据块chunk数。这既避免了对冻结状态的重复计数也避免了将一个本应宽泛的直接探测强制推向串行路径。