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となります。
関連情報
