system.processors_profile_log

Querying in ClickHouse Cloud

このシステムテーブルのデータは、ClickHouse Cloudの各ノードにローカルで保管されています。そのため、すべてのデータの完全なビューを取得するには、clusterAllReplicas 関数が必要です。詳細については こちら をご覧ください。

该表包含处理器级别的分析信息（可以在 EXPLAIN PIPELINE 中找到该信息）。

列：

• hostname (LowCardinality(String)) — 执行查询的服务器的主机名。
• event_date (Date) — 事件发生的日期。
• event_time (DateTime) — 事件发生的日期和时间。
• event_time_microseconds (DateTime64) — 事件发生时的微秒精度的日期和时间。
• id (UInt64) — 处理器的 ID
• parent_ids (Array(UInt64)) — 父处理器的 IDs
• plan_step (UInt64) — 创建该处理器的查询计划步骤的 ID。如果处理器不是从任何步骤添加的，则该值为零。
• plan_group (UInt64) — 如果处理器是由查询计划步骤创建的，则为处理器的组。组是从同一查询计划步骤添加的处理器的逻辑分区。组仅用于美化 EXPLAIN PIPELINE 结果。
• initial_query_id (String) — 初始查询的 ID（用于分布式查询执行）。
• query_id (String) — 查询的 ID
• name (LowCardinality(String)) — 处理器的名称。
• elapsed_us (UInt64) — 该处理器执行的微秒数。
• input_wait_elapsed_us (UInt64) — 该处理器等待数据（来自其他处理器）的微秒数。
• output_wait_elapsed_us (UInt64) — 该处理器因输出端口已满而等待的微秒数。
• input_rows (UInt64) — 被处理器消耗的行数。
• input_bytes (UInt64) — 被处理器消耗的字节数。
• output_rows (UInt64) — 由处理器生成的行数。
• output_bytes (UInt64) — 由处理器生成的字节数。 示例

查询：

结果：

在这里你可以看到：

• ExpressionTransform 正在执行 sleep(1) 函数，因此它的 work 将耗时 1e6，所以 elapsed_us > 1e6。
• SourceFromSingleChunk 需要等待，因为 ExpressionTransform 在执行 sleep(1) 时不接受任何数据，因此它将处于 PortFull 状态 1e6 微秒，因此 output_wait_elapsed_us > 1e6。
• LimitsCheckingTransform/NullSource/LazyOutputFormat 需要等待，直到 ExpressionTransform 执行 sleep(1) 来处理结果，因此 input_wait_elapsed_us > 1e6。

另见

• EXPLAIN PIPELINE