此模組收集的統計資訊可透過名為 pg_stat_statements 的檢視取得。此檢視針對資料庫 ID、使用者 ID、查詢 ID 和是否為最上層陳述式的每種不同組合包含一個資料列（最多可追蹤的相異陳述式數量上限）。檢視的欄位顯示在 表格 F.21 中。

基於安全理由，只有超級使用者和具有 pg_read_all_stats 角色權限的角色才能看到其他使用者執行的查詢的 SQL 文字和 queryid。但是，如果視窗已安裝在他們的資料庫中，其他使用者可以看到統計資料。

當可規劃的查詢（也就是 SELECT、INSERT、UPDATE、DELETE 和 MERGE）和公用程式命令根據內部雜湊計算具有相同的查詢結構時，它們會合併為單個 pg_stat_statements 項目。通常，如果兩個查詢在語義上等效，但查詢中出現的文字常數值除外，則會將它們視為相同。

當常數的值已被忽略，以便將查詢與其他查詢匹配時，該常數將被 pg_stat_statements 顯示中的參數符號（例如 $1）替換。查詢文字的其餘部分是第一個查詢的文字，該查詢具有與 pg_stat_statements 項目關聯的特定 queryid 雜湊值。

在 pg_stat_statements 中可能會觀察到可以應用哪些正規化的查詢具有常數值，尤其是在條目解除配置率很高時。為了降低這種情況發生的可能性，請考慮增加 pg_stat_statements.max。 下文 第 F.30.2 節討論的 pg_stat_statements_info 檢視表提供了有關條目解除配置的統計資訊。

在某些情況下，具有明顯不同文字的查詢可能會合併到單個 pg_stat_statements 條目中。 通常，這只會發生在語義上等效的查詢中，但存在雜湊碰撞導致不相關的查詢合併為一個條目的小機率（但是，這不會發生於屬於不同使用者或資料庫的查詢）。

由於 queryid 雜湊值是在查詢的剖析後分析表示式上計算的，因此相反的情況也可能發生：如果具有相同文字的查詢由於諸如不同的 search_path 設定等因素而具有不同的含義，則它們可能會顯示為單獨的條目。

pg_stat_statements 的使用者可能希望使用 queryid（可能與 dbid 和 userid 結合使用）作為每個條目比其查詢文字更穩定和可靠的識別符號。 但是，重要的是要理解，對於 queryid 雜湊值的穩定性只有有限的保證。 由於識別符號是從剖析後分析樹衍生出來的，因此它的值是此表示式中出現的內部物件識別符號的函數，以及其他因素。 這有一些違反直覺的含義。 例如，如果兩個查詢引用在兩個查詢的執行之間被刪除並重新建立的表，則 pg_stat_statements 會認為兩個表面上相同的查詢是不同的。 雜湊處理過程也對機器架構和平台的其他方面差異很敏感。 此外，不能假定 queryid 在 PostgreSQL 的主要版本之間是穩定的。

期望參與基於實體 WAL 重播的複寫的兩個伺服器對於同一查詢具有相同的 queryid 值。 但是，邏輯複寫方案不保證副本在所有相關細節上都相同，因此 queryid 不會成為跨一組邏輯副本累積成本的有用識別符號。 如果有疑問，建議直接測試。

通常，可以假定 queryid 值在 PostgreSQL 的次要版本發布之間是穩定的，前提是實例在同一機器架構上執行，並且目錄中繼資料詳細資訊匹配。 只有在萬不得已的情況下，才會在次要版本之間打破相容性。

用於替代表徵性查詢文字中常數的參數符號從原始查詢文字中最高 $n 參數後的下一個數字開始，如果沒有，則從 $1 開始。 值得注意的是，在某些情況下，可能存在影響此編號的隱藏參數符號。 例如，PL/pgSQL 使用隱藏的參數符號將函數區域變數的值插入到查詢中，因此 PL/pgSQL 語句（如 SELECT i + 1 INTO j）將具有如 SELECT i + $2 這樣的代表性文字。

代表性查詢文字保存在外部磁碟檔案中，並且不佔用共享記憶體。 因此，即使是很長的查詢文字也可以成功儲存。 但是，如果累積了許多長查詢文字，則外部檔案可能會變得難以管理地龐大。 如果發生這種情況，作為一種恢復方法，pg_stat_statements 可以選擇捨棄查詢文字，之後 pg_stat_statements 檢視表中的所有現有條目都將顯示空值 query 欄位，但與每個 queryid 相關聯的統計資訊會被保留。 如果發生這種情況，請考慮減少 pg_stat_statements.max 以防止再次發生。

由於計畫和執行統計資訊是在各自的結束階段更新的，並且僅適用於成功的操作，因此 plans 和 calls 並不總是預期匹配。 例如，如果成功計畫了一個語句，但在執行階段失敗，則僅更新其計畫統計資訊。 如果因為使用了快取的計畫而跳過了計畫，則僅更新其執行統計資訊。

pg_stat_statements 模組本身的統計資訊會被追蹤，並透過名為 pg_stat_statements_info 的檢視表提供。 此檢視表僅包含單列。 檢視表的欄位顯示在 表格 F.22 中。

此模組需要與 pg_stat_statements.max 成比例的額外共用記憶體。 請注意，無論何時載入模組，都會消耗此記憶體，即使 pg_stat_statements.track 設定為 none 也是如此。

這些參數必須在 postgresql.conf 中設定。 一般用法可能是

# postgresql.conf
shared_preload_libraries = 'pg_stat_statements'

compute_query_id = on
pg_stat_statements.max = 10000
pg_stat_statements.track = all

bench=# SELECT pg_stat_statements_reset();

$ pgbench -i bench
$ pgbench -c10 -t300 bench

bench=# \x
bench=# SELECT query, calls, total_exec_time, rows, 100.0 * shared_blks_hit /
               nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
          FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5;
-[ RECORD 1 ]---+--------------------------------------------------​------------------
query           | UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2
calls           | 3000
total_exec_time | 25565.855387
rows            | 3000
hit_percent     | 100.0000000000000000
-[ RECORD 2 ]---+--------------------------------------------------​------------------
query           | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
calls           | 3000
total_exec_time | 20756.669379
rows            | 3000
hit_percent     | 100.0000000000000000
-[ RECORD 3 ]---+--------------------------------------------------​------------------
query           | copy pgbench_accounts from stdin
calls           | 1
total_exec_time | 291.865911
rows            | 100000
hit_percent     | 100.0000000000000000
-[ RECORD 4 ]---+--------------------------------------------------​------------------
query           | UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2
calls           | 3000
total_exec_time | 271.232977
rows            | 3000
hit_percent     | 98.8454011741682975
-[ RECORD 5 ]---+--------------------------------------------------​------------------
query           | alter table pgbench_accounts add primary key (aid)
calls           | 1
total_exec_time | 160.588563
rows            | 0
hit_percent     | 100.0000000000000000


bench=# SELECT pg_stat_statements_reset(0,0,s.queryid) FROM pg_stat_statements AS s
            WHERE s.query = 'UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2';

bench=# SELECT query, calls, total_exec_time, rows, 100.0 * shared_blks_hit /
               nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
          FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5;
-[ RECORD 1 ]---+--------------------------------------------------​------------------
query           | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
calls           | 3000
total_exec_time | 20756.669379
rows            | 3000
hit_percent     | 100.0000000000000000
-[ RECORD 2 ]---+--------------------------------------------------​------------------
query           | copy pgbench_accounts from stdin
calls           | 1
total_exec_time | 291.865911
rows            | 100000
hit_percent     | 100.0000000000000000
-[ RECORD 3 ]---+--------------------------------------------------​------------------
query           | UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2
calls           | 3000
total_exec_time | 271.232977
rows            | 3000
hit_percent     | 98.8454011741682975
-[ RECORD 4 ]---+--------------------------------------------------​------------------
query           | alter table pgbench_accounts add primary key (aid)
calls           | 1
total_exec_time | 160.588563
rows            | 0
hit_percent     | 100.0000000000000000
-[ RECORD 5 ]---+--------------------------------------------------​------------------
query           | vacuum analyze pgbench_accounts
calls           | 1
total_exec_time | 136.448116
rows            | 0
hit_percent     | 99.9201915403032721

bench=# SELECT pg_stat_statements_reset(0,0,0);

bench=# SELECT query, calls, total_exec_time, rows, 100.0 * shared_blks_hit /
               nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
          FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5;
-[ RECORD 1 ]---+--------------------------------------------------​---------------------------
query           | SELECT pg_stat_statements_reset(0,0,0)
calls           | 1
total_exec_time | 0.189497
rows            | 1
hit_percent     |
-[ RECORD 2 ]---+--------------------------------------------------​---------------------------
query           | SELECT query, calls, total_exec_time, rows, $1 * shared_blks_hit /          +
                |                nullif(shared_blks_hit + shared_blks_read, $2) AS hit_percent+
                |           FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT $3
calls           | 0
total_exec_time | 0
rows            | 0
hit_percent     |

Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>。 Peter Geoghegan 新增的查詢正規化 <peter@2ndquadrant.com>。