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。プロセッサーがどのステップからも追加されていない場合、この値は 0。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 us がかかり、その結果elapsed_us> 1e6 となります。SourceFromSingleChunkは待機する必要があります。これは、ExpressionTransformがsleep(1)の実行中はデータを一切受け付けないためで、その 1e6 us のあいだPortFull状態となり、結果としてoutput_wait_elapsed_us> 1e6 となります。LimitsCheckingTransform/NullSource/LazyOutputFormatは、結果を処理するためにExpressionTransformがsleep(1)の実行を完了するまで待機する必要があるため、input_wait_elapsed_us> 1e6 となります。
関連項目