---
title: "ClickHouse Cloud における Postgres Query Insights のご紹介"
date: "2026-09-25T07:22:08.462Z"
author: "Amog Iska"
category: "Engineering"
excerpt: "ClickHouse Managed Postgres 向けに Query Insights のプレビュー提供を開始しました。データベースが実行する全クエリパターンを影響度順にランク付けし、各クエリが遅い原因を診断・可視化します。"
---
# ClickHouse Cloud における Postgres Query Insights のご紹介
クエリが遅いことには必ず理由があります。Postgres は多くのシグナルを出力しています。**pg_stat_ch** はそれらをステートメント単位で収集し、**Postgres Query Insights** はそれらを統合して可視化します。
**Query Insights** は、現在 [ClickHouse Cloud Managed Postgres](https://clickhouse.com/cloud/postgres) 向けにプレビュー版を提供しています。データベースが実行するすべてのクエリパターンを影響度順にランク付けし、各クエリが遅い理由を完全な診断情報とともに提示します。[pg_stat_ch](https://github.com/clickhouse/pg_stat_ch) は、ステートメントごとのテレメトリを ClickHouse へストリーミングし、Insights を実現するために私たちが開発したオープンソースの拡張機能です。
## 提供される機能 {#what-you-get}
実際の調査手順に沿った、3 つの画面を提供します。
### Overview(概要) {#overview}
**Query insights** タブを開くと、1 画面に収まるデータベースヘルスチェック画面が表示されます。
- クエリボリューム
- エラー率
- キャッシュヒット率
- ワークロードを実際に構成している各種オペレーションの割合
- 指定した期間におけるレイテンシ
1 つの画面を見るだけで、データベースが正常かどうかが分かります。詳細を掘り下げたり、複数のデータを照合したり、複数のタブを同時に気にかける必要はありません。
### Slow patterns(低速なパターン) {#slow-patterns}
概要画面で問題が見つかった場合、調査はパターンテーブルから始まります。データベースが実行したクエリパターンが 1 行ずつ表示され、調査したい切り口に合わせてソートできます。
- 総実行時間
- 総 CPU 時間
- エラー数
- 最大レイテンシ
- P95
**total duration**(総実行時間)でソートすると、通常「何が最もコスト要因になっているか」の答えが最上位のパターンとして現れます。個別に見て最も遅いパターンとは限りません。1 回の実行に 3 秒かかるクエリよりも、12 ミリ秒で 1 日に 800 万回実行されるクエリの方が深刻な影響を与えることがあります。
ソート順を変えるごとに異なる視点が得られます。**Total CPU** はコンピュート負荷の高いパターンを示します。**Error count** は繰り返し発生している失敗をあぶり出します。**P95** は極端な外れ値を捉えます。これらを組み合わせることで、漠然とした問題の兆候から、具体的な調査着手ポイントへと絞り込めます。
テーブルは調査対象のワークロードに合わせて以下の条件で絞り込めます。
- データベース
- アプリケーション名
- オペレーション種別
- ユーザー
_「sales データベースで orders サービスが何を実行しているかだけを表示したい」_
### Detail(詳細) {#detail}
パターンの行をクリックすると、フライアウトパネルが開きます。ここが調査の「着地点」です。
フライアウトは、指定した期間におけるそのパターンのすべての実行結果をまとめ、なぜ遅いのかを説明するカウンターを集計します。
- パーセンタイルレイテンシ (p95/p99)
- CPU 別の時間消費の内訳
- キャッシュとディスクからそれぞれ読み取られたデータ量
- 一時ファイル(temp)に退避されたブロック数(読み取られたブロック数)
- 本来起動すべき並行ワーカーが起動しなかった箇所
- WAL ボリュームの発生元
低速なパターンの診断に必要なすべての情報が、ひと目でわかる 1 か所に集約されています。
## レイテンシ悪化の調査:エンドツーエンドの例 {#a-latency-regression-end-to-end}
具体的な調査の流れを見てみましょう。受注ダッシュボードを支えるマネージド Postgres インスタンスを運用しているとします。過去 1 週間にわたり、ダッシュボードのメインエンドポイントの p99 レイテンシが徐々に上昇しています。p50 に問題はありません。ユーザーからは時折、クエリの遅延やタイムアウトが報告されています。Query Insights を開いて、どのクエリに原因があるのかを特定します。
**1. タブを開く**
対象のインスタンスにアクセスし、**Query insights** をクリックします。統計グリッドを確認すると、クエリボリュームは横ばい、エラー率も横ばい、キャッシュヒット率は 99.4% となっています。一見すると警戒すべき兆候はありません。
**2. チャートのメトリクスを切り替える**
デフォルトのチャートは `query_count` です。これを `p99_duration` に切り替えます。1 週間にわたってグラフの線が右肩上がりに伸びています。p50 は横ばいのままです。性能低下は実際に発生しており、末尾のテールレイテンシで起きていることが分かります。
**3. 低速なパターンを見つける**
パターンテーブルを **Total Duration**、**P99**、または **Avg Duration** の降順でソートします。最上位の行には以下が表示されます。
SELECT *
FROM orders
JOIN customers ON orders.customer_id = customers.id
WHERE orders.status = $1
ORDER BY orders.created_at DESC
LIMIT $2;
**4. パターンのフライアウトを開く**
- 平均レイテンシは数ミリ秒台と健全な状態です
- p99 は数百ミリ秒に達しています(末尾の外れ値が実際の問題です)
- キャッシュヒット率は 100% に近いため、ボトルネックは共有バッファの I/O ではありません
- 読み取り専用クエリのため、想定通り WAL バイト数はゼロです
フライアウトで最近の実行状況をさらに詳しく確認します。
- `Temp block ops` がゼロではありません(ソート処理がディスクに退避されています)
- `Parallel workers launched` が `parallel workers planned` を大きく下回っています
この組み合わせが重要です。書き込みの問題ではありません。バッファプールの問題でもありません。クエリがソート処理中にディスクへ退避(スピル)しており、このスピルがテールレイテンシを押し上げているのです。
**5. 修正する**
スピルの発生が特定できたら、次のステップは `EXPLAIN (ANALYZE, BUFFERS)` を使った確認です。実行計画では、Sort ノードがディスクに退避しているとマークされ、実行中にソートが実際に消費したメモリ量も表示されます。健全な実行計画であれば `Sort Method: quicksort Memory: NkB` と表示される箇所に、`Sort Method: external merge Disk: NkB` と出力されます。この Disk の数値から、ソートによって書き出された一時ファイルのサイズが分かります。設定されている `work_mem` と比較してください。わずかな超過であればチューニングの問題であり、何倍にも達している場合は実行計画の形状(クエリ設計)自体の問題です。
原因が分かれば対策は明確です。フィルタリングとソートの両方をカバーするインデックスを追加して Postgres がソート処理自体をスキップできるようにするか、該当するロールやセッションの `work_mem` を引き上げてソートをメモリ内で完結できるようにするか、あるいはその両方を実施します。Query Insights は問題のあるパターンを指し示し、EXPLAIN ANALYZE は具体的な対処法を教えてくれます。
## 健全なインスタンスの状態 {#healthy-instance}
修正を適用すると、その効果は Query Insights にすぐに現れます。パターンの詳細からスピルが消え、並行ワーカーが計画通りに起動し、p99 は p50 と同等レベルまで低下します。概要画面でもそれが裏付けられます。キャッシュヒット率は安定し、新たなエラーは発生せず、レイテンシ全体が安定します。これでインスタンスは再び健全な状態に戻りました。
健全なインスタンスには共通する特徴があります。キャッシュヒット率は 90% 台後半を維持します。クエリボリュームはアプリケーションのトラフィックに連動して推移し、不規則な動きは見られません。エラー率は横ばいかゼロを維持します。パターンテーブルには突出した悪化要因がなく、総実行時間は多数のパターンに分散して、特定のパターンだけが過度に突出することはありません。各レイテンシパーセンタイルは互いに近い値を保ち、p99 も p50 の妥当な倍率の範囲内に収まります。すべての指標がこの状態であれば、Query Insights は最も望ましい形で「静かな」状態を保ちます。
## アーキテクチャと設計方針 {#how-its-built}
本プロダクトの背後にあるいくつかの設計上の選択を紹介します。
**ユーザーと同じエンジンを採用。** Insights のバックエンドには ClickHouse Cloud を採用しています。この規模とデータ形状において、データの保存とクエリを最も高速に処理できると私たちが確信している手法です。負荷の高い Postgres インスタンスから発生するクエリ単位のテレメトリは、1 日あたり数百万行に達します。ClickHouse は多数のプロデューサーからのデータ取り込みに対応し、列指向の圧縮技術により数か月分の実行詳細を低コストで保持でき、数十億行に対する 1 秒未満の集計を可能にします。高負荷なデータベースの過去 1 週間や 1 か月分の実行ステートメント全体をスライスして分析する場合でも、UI のインタラクティブ性は維持され、パーセンタイルの再計算、ランキングの並べ替え、フィルター変更も極めて高速に動作します。
**ネットワークに送信する前に Postgres 側で正規化。** Postgres がステートメントをパースし、クエリテキスト内のすべてのリテラルの位置を特定した直後である parse-analyze フェーズにフックを配置しています。各リテラルをプレースホルダー(`$1`、`$2`、…)に置き換え、生成されたパターンを queryid をキーとしてバックエンドごとの LRU キャッシュに保持します。エグゼキューターがステートメントの処理を終えると、キューに追加される前に、このキャッシュされたパターンがイベントに付与されます。具体的な値が含まれた実際のステートメントがデータベースの外部に出ることはありません。**設計上、テレメトリストリームに PII(個人を特定できる情報)や PHI(保護対象保健情報)が含まれることはありません。**
**データベース本体への影響を最小化。** ステートメントあたりのプロデューサーのオーバーヘッドは約 3% に抑えられています。エンキュー処理には共有メモリリングバッファに対するノンブロッキングの try-lock を使用しています。ロックの競合が発生した場合、プロデューサーはスピンやブロックを行わず、ローカルでキューイングしてトランザクション終了時にフラッシュします。高負荷時には、Postgres にバックプレッシャーをかけるのではなく、カウンターを記録しながらイベントを破棄します。「計測対象自身のボトルネックになってはならない」というのがテレメトリの鉄則です。
**オープンソース。** [pg_stat_ch](https://github.com/clickhouse/pg_stat_ch) は Apache 2.0 ライセンスで公開されています。任意の Postgres 環境で実行し、任意の ClickHouse に送信できます。
**集計値ではなく未加工の生イベント。** pg_stat_ch は、サンプリングを適用した上で、実行されたステートメントごとに 1 つの生イベント(トップレベルおよびネストされたもの)を出力します。UI に表示されるすべてのパーセンタイル、ランキング、ブレークダウンは、同一のイベントストリームに対して実行される ClickHouse クエリによって算出されています。
## 今後の展望 {#whats-next}
私たちが現在開発を進めている主な機能として、UI が使用しているものと同じデータを公開する、エージェント型(Agentic)時代向けに特化した **Open API** があります。AI エージェントにパターンの集計値や実行ごとのカウンターへの直接アクセスを提供することで、AI が手元のデータを分析して自律的にボトルネックを特定し、アプリケーションの低速化や障害が発生している箇所の修正対応を行えるようになります。
この Open API と、それがどのようにエージェントを支援するのかについて先行デモをご紹介します。私たちはこれを [HouseClick](https://github.com/ClickHouse/HouseClick) というデモアプリケーションに対してテストしました。
デモのプルリクエストはこちらです:[https://github.com/ClickHouse/HouseClick/pull/55](https://github.com/ClickHouse/HouseClick/pull/55)
また、CPU や I/O カウンターの数値はいずれも小さいもののクエリに数百ミリ秒かかっているようなケースに対応するため、Postgres が実際に何を待機していたのか(I/O、ロック、バッファピン、IPC、クライアント)を実行単位で特定できる **wait events**(待機イベント)機能の開発も進めています。
さらに、低速クエリの実行計画内のボトルネック特定を支援するため、EXPLAIN プランの表示機能も追加する予定です。データベースの負荷を管理できるように、`BUFFERS` なしで `ANALYZE` を実行したり、プラン収集対象とするクエリレイテンシのしきい値を設定したりするなど、柔軟に設定できるようにすることを目指しています。
これらのデータをもとに、インデックスのヒント、`work_mem` のチューニング提案、autovacuum のガイダンスなど、具体的なアクションにつながる推奨事項を提供し、「次に何をすべきか」を判断する認知的負荷を軽減する予定です。加えて、p99 レイテンシの倍増、新たな高負荷パターンの出現、設定したしきい値を超えるエラー数の増加などを検知する性能低下アラートの追加も計画しています。
## お試しください {#try-it}
ClickHouse Cloud にサインアップして Postgres サービスをプロビジョニングすることで、Query Insights をお試しいただけます。すでに Postgres サービスをご利用中で Query Insights が表示されない場合は、サポートチケットを作成していただければ有効化いたします。利用開始にあたっては以下をご参照ください。
- [ClickHouse Managed Postgres にサインアップする](https://clickhouse.com/cloud/postgres)
- [クイックスタートガイドを見る](https://clickhouse.com/docs/ja/products/managed-postgres/quickstart)
- [ドキュメントを見る](https://clickhouse.com/docs/ja/products/managed-postgres/overview)
Postgres 向け Query Insights を支える拡張機能は、Apache 2.0 ライセンスのもと [github.com/clickhouse/pg_stat_ch](https://github.com/clickhouse/pg_stat_ch) で公開されています。課題の起票、PR の送信、手元の任意の Postgres での実行など、ぜひご活用ください。
---
## ClickHouse Managed Postgres にサインアップ
ClickHouse Managed Postgres の利用について詳しく知りたい方はこちらをご覧ください。
[サインアップ](https://clickhouse.com/cloud/postgres?loc=blog-cta-2294-clickhouse-managed-postgres&utm_blogctaid=2294)
---