統計情報の収集によって問い合わせの実行に少しオーバーヘッドが加わりますので、システムは情報を収集するようにもしないようにも設定することができます。 これは通常はpostgresql.conf内で設定される、設定パラメータによって制御されます （設定パラメータの設定についての詳細は第19章を参照してください）。

track_activitiesパラメータにより、すべてのサーバプロセスで現在実行されているコマンドを監視することができます。

track_countsパラメータは、テーブルおよびインデックスアクセスに関する統計情報を収集するかどうか制御します。

track_functionsパラメータは、ユーザ定義関数の使用状況を追跡するかどうかを指定できます。

track_io_timingパラメータは、ブロック読み取りおよび書き込み回数の監視するかどうかを指定できます。

通常、これらの変数は全てのサーバプロセスに適用できるようにpostgresql.conf内で設定されます。 しかし、SETコマンドを使用して、個別のセッションで有効または無効にできます。 （一般ユーザがその活動を管理者に隠すことを防止するために、スーパーユーザのみがSETを使用してこれらのパラメータを変更できます。）

統計情報コレクタは収集した情報を他のPostgreSQLプロセスに一時ファイルを介して送信します。 これらのファイルはstats_temp_directoryで指名されたディレクトリ、デフォルトはpg_stat_tmp内に格納されます。 性能を向上させるために、stats_temp_directoryをRAMベースのファイルシステムを指し示すようにして、物理的なI/O要求を減らすことができます。 サーバが正しくシャットダウンした際は、統計情報がサーバの再起動を跨がって保持されるように、統計情報データの永続的なコピーがpg_statサブディレクトリに格納されます。 サーバ起動時にリカバリが実施される場合(例えば、即時シャットダウンやサーバクラッシュ、ポイントインタイムリカバリ)、統計カウンタをすべてリセットします。

システムの現在の状態を表示するために、いくつかの定義済みのビューがあり、表 28.1に一覧されています。 また、統計情報の収集結果を表示するために、他にもいくつかのビューがあり、表 28.2に一覧されています。 他にも、28.2.3で説明する、基礎的な統計情報関数を使用した独自のビューを構築することもできます。

この統計情報を使用して、収集されるデータを監視する場合、この情報は即座に更新されないことを認識することが重要です。 個別のサーバプロセスは、待機状態になる直前に、新しい統計情報に関する数をコレクタに送信します。 ですので、実行中の問い合わせやトランザクションは表示上の総和には影響を与えません。 また、コレクタ自体もおよそPGSTAT_STAT_INTERVAL（サーバ構築時に変更しない限り500 ms）ミリ秒に一度新しい報告を出力します。 ですので、表示上の情報は実際の活動から遅れて表示されます。 しかし、track_activitiesで収集される現在の問い合わせの情報は常に最新です。

この他の重要なポイントは、いつサーバプロセスが統計情報を表示するように尋ねられるかです。 サーバプロセスは、まずコレクタによって発行された最も最近の報告を取り出します。 そして、現在のトランザクションが終わるまで、全ての統計情報ビューと関数においてこのスナップショットを使用し続けます。 ですから、現在のトランザクションを続けている間、統計情報は一定の情報を示します。 同様に、全セッションの現在の問い合わせに関する情報も、そうした情報がトランザクションで最初に要求された時に収集され、そのトランザクションの間同じ情報が表示されます。 これはバグではなく、特徴です。 なぜなら、これにより、知らない間に値が変更することを考慮することなく、統計情報に対して複数の問い合わせを実行し、その結果を相関することができるからです。 しかし、各問い合わせで新しい結果を取り出したい場合は、確実にトランザクションブロックの外側でその問い合わせを行ってください。 他にもpg_stat_clear_snapshot()を呼び出すこともできます。 これは現在のトランザクションの統計情報スナップショットを（もしあれば）破棄します。 次に統計情報を使用する場合に新しいスナップショットを取り出すことになります。

トランザクションからは、pg_stat_xact_all_tables、pg_stat_xact_sys_tables、pg_stat_xact_user_tables、pg_stat_xact_user_functions、およびこれらのビューの元となっている関数を通じて、自身の統計情報(まだコレクタに送られていない)も参照することができます。 これらの数値はトランザクション中に継続的に更新されていくため上記の様な(静的な情報を示す)振る舞いとはなりません。

インデックス単位の統計情報は、どのインデックスが使用され、どの程度効果があるのかを評価する際に、特に有用です。

pg_statio_ビューは主に、バッファキャッシュの効率を評価する際に有用です。 実ディスク読み取りの数がバッファヒットの数よりもかなり少ないのであれば、そのキャッシュはカーネル呼び出しを行うことなく、ほとんどの読み取り要求を満足させています。 しかし、PostgreSQLバッファキャッシュに存在しないデータはカーネルのI/Oキャッシュにある可能性があり、そのため、物理的な読み取りを行うことなく取り出される可能性があるというPostgreSQLのディスクI/Oの取り扱いのため、これらの統計情報は、完全な論拠を提供しません。 PostgreSQLのI/O動作に関するより詳細な情報を入手したいのであれば、PostgreSQL統計情報コレクタとカーネルのI/Oの取り扱いの監視を行うオペレーティングシステムユーティリティを組み合わせることを勧めます。

pg_stat_activityはサーバプロセス毎に、そのプロセスの現在の活動に関連する情報を表示する１行を持ちます。

以下に、待機イベントが表示される例を示します。

SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event is NOT NULL;
 pid  | wait_event_type |  wait_event
------+-----------------+---------------
 2540 | Lock            | relation
 6644 | LWLock          | ProcArrayLock
(2 rows)

pg_stat_replicationビューには、WAL送信プロセス毎に、送信処理に接続したスタンバイサーバへのレプリケーションに関する統計情報を示す１行を保持します。 直接接続されたサーバのみが一覧表示されます。 下流のスタンバイサーバに関する情報はありません。

pg_stat_replicationビューで報告される経過時間は、最近のWALが書き込まれ、吐き出され、再生されるのに要した時間の測定結果であり、また、送信サーバがそれを知るためのものです。 リモートサーバが同期スタンバイとして設定されている場合、これらの時間は、同期コミットの各レベルによって引き起こされた（あるいは引き起こされたであろう）コミットの遅延を表します。 非同期スタンバイの場合は、replay_lag列は最近のトランザクションが問い合わせに対して可視になったときまでの遅延を近似します。 スタンバイサーバが送信サーバに完全に追いつき、WALの活動がなくなった状態のときは、最も直近に測定された経過時間が短い間、表示され続け、その後はNULLとなります。

経過時間は物理レプリケーションの場合は自動的に機能します。 ロジカルデコーディングのプラグインはオプションで追跡メッセージを発することができますが、そうしなければ追跡機能は単にNULLの経過時間を表示します。

pg_stat_wal_receiverビューは、１行のみの形式で、受信サーバが接続したサーバからWALレシーバに関する統計情報を表示します。

pg_stat_subscriptionには、各サブスクリプションのメインワーカに対して1行が含まれ（ワーカが実行中でないときはPIDがNULLになります）、さらにサブスクライブされたテーブルの初期データコピーを処理するワーカについて別の行があります。

pg_stat_sslビューは、バックエンドプロセスおよびWAL送信プロセスごとに1行を保持し、接続上でのSSLの使用に関する統計情報を示します。 pg_stat_activityまたはpg_stat_replicationとpid列で結合することで、接続に関するより詳細な情報を取得することができます。

pg_stat_archiverは常に、クラスタのアーカイバプロセスに関するデータを含む１つの行を持ちます。

pg_stat_bgwriterビューは常に、クラスタのグローバルデータに関する１つの行を持ちます。

pg_stat_databaseには、クラスタ内のデータベース毎にデータベース全体の統計情報を示す１行が含まれます。

pg_stat_database_conflictsビューは、データベース毎に１行を保持し、スタンバイサーバでのリカバリと競合するためにキャンセルされた問い合わせに関するデータベース全体の統計情報を示します。 マスタサーバでは競合は発生しませんので、スタンバイサーバ上の情報のみが保持されます。

pg_stat_all_tablesビューは現在のデータベース内のテーブル（TOASTテーブルを含む）毎に１行の形式で、特定のテーブルへのアクセスに関する統計情報を表示します。 pg_stat_user_tablesおよびpg_stat_sys_tablesビューにも同じ情報が含まれますが、それぞれユーザテーブルとシステムテーブルのみにフィルタされています。

pg_stat_all_indexesビューは、現在のデータベース内のインデックス毎に、特定のインデックスへのアクセスに関する統計情報を示す１行を保持します。 pg_stat_user_indexesとpg_stat_sys_indexesも同じ情報を保持しますが、ユーザ向けのインデックスとシステム向けのインデックスに対する行のみを保持するようにフィルタ処理されています。

単純なインデックススキャン、「ビットマップ」インデックススキャン、あるいはオプティマイザによりインデックスが使用されることがあります。 ビットマップスキャンでは、複数のインデックスの出力をANDやOR規則で組み合わせることができます。 このため、ビットマップスキャンが使用される場合、特定インデックスと個々のヒープ行の取り出しとを関連づけることが困難です。 したがってビットマップスキャンでは、使用したインデックスのpg_stat_all_indexes.idx_tup_read個数を増やし、そのテーブルのpg_stat_all_tables.idx_tup_fetch個数を増やしますが、pg_stat_all_indexes.idx_tup_fetchを変更しません。 オプティマイザもインデックスにアクセスし、提供された定数値がオプティマイザの統計情報に記録された範囲の外側にあるときに、それを検査します。 これはオプティマイザの統計情報が古いかもしれないからです。

pg_statio_all_tablesビューは現在のデータベース内のテーブル（TOASTテーブルを含む）ごとに、特定のテーブルのI/Oに関する統計情報を示す１行を保持します。 pg_statio_user_tablesとpg_statio_sys_tablesには同じ情報が保持されますが、ユーザテーブルとシステムテーブルに関する行のみを持つようにフィルタ処理がなされています。

pg_statio_all_indexesビューは、現在のデータベース内のインデックス毎に、特定のインデックスへのI/Oに関する統計情報を持つ１行を保持します。 pg_statio_user_indexesとpg_statio_sys_indexesも同じ情報を保持しますが、それぞれユーザ向けのインデックスとシステム向けのインデックスに対する行のみを保持するようにフィルタ処理されています。

pg_statio_all_sequencesビューは現在のデータベース内のシーケンスごとに、特定シーケンスにおけるI/Oに関する統計情報を示す１行を保持します。

pg_stat_user_functionsビューは追跡された関数毎に、その関数の実行に関する統計情報を１行保持します。 track_functionsパラメータは関数が追跡されるかどうかを正確に制御します。

統計情報を参照する他の方法は、上述の標準ビューによって使用される基礎的な統計情報アクセス関数と同じ関数を使用した問い合わせを作成することで設定することができます。 こうした関数の名前などに関する詳細については、標準ビューの定義を参照してください。 （例えばpsqlでは\d+ pg_stat_activityを発行してください。） データベースごとの統計情報についてのアクセス関数は、どのデータベースに対して報告するのかを識別するためにデータベースのOIDを取ります。 テーブルごと、インデックスごとの関数はテーブルの、もしくはインデックスのOIDを取ります。 関数ごとの統計情報の関数は、関数のOIDを取ります。 これらの関数を使用して参照できるテーブルとインデックス、および関数は現在のデータベース内のものだけであることに注意してください。

その他の統計情報収集に関連した関数を表 28.19に示します。

pg_stat_activityビューの基礎となるpg_stat_get_activity関数は、 各バックエンドプロセスに関して利用可能な情報をすべて含むレコード集合を返します。 この情報の一部のみを入手することがより簡便である場合があるかもしれません。 このような場合、表 28.20に示す、古めのバックエンド単位の統計情報アクセス関数を使用することができます。 これらのアクセス関数は、１から現在活動中のバックエンドの個数までの値を取る、バックエンドID番号を使用します。 pg_stat_get_backend_idset関数は、これらの関数を呼び出すために、活動中のバックエンド毎に１行を生成する簡便な方法を提供します。 例えば以下はすべてのバックエンドについてPIDと現在の問い合わせを示します。

SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
       pg_stat_get_backend_activity(s.backendid) AS query
    FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;