system.processors_profile_log

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)) — 親プロセッサーのID。
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 usまでで、output_wait_elapsed_us > 1e6です。
LimitsCheckingTransform/NullSource/LazyOutputFormatは、結果を処理するためにExpressionTransformがsleep(1)を実行するまで待機する必要があり、そのためinput_wait_elapsed_us > 1e6です。

参照

EXPLAIN PIPELINE