該模組收集的統計資訊可透過一個名為 pg_stat_statements 的檢視獲得。此檢視為每個資料庫 ID、使用者 ID、查詢 ID 的不同組合以及它是否為頂級語句（最多可跟蹤的獨立語句數量）包含一行。檢視的列在表 F.22 中顯示。

出於安全原因，只有超級使用者和具有 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。pg_stat_statements_info 檢視（下面在 F.32.2. pg_stat_statements_info 檢視中討論）提供了關於條目去分配的統計資訊。

在某些情況下，具有明顯不同文字的查詢可能會合併到一個 pg_stat_statements 條目中；如上所述，這對於語義等效的查詢是預期發生的。此外，如果查詢之間唯一的區別是常量列表的元素數量，則該列表將被壓縮成一個元素，但會顯示一個帶註釋的列表指示符

=# SELECT pg_stat_statements_reset();
=# SELECT * FROM test WHERE a IN (1, 2, 3, 4, 5, 6, 7);
=# SELECT * FROM test WHERE a IN (1, 2, 3, 4, 5, 6, 7, 8);
=# SELECT query, calls FROM pg_stat_statements
   WHERE query LIKE 'SELECT%';
-[ RECORD 1 ]------------------------------
query | SELECT * FROM test WHERE a IN ($1 /*, ... */)
calls | 2

除了這些情況之外，還存在雜湊衝突導致不相關查詢合併成一個條目的可能性。（然而，這不會發生在屬於不同使用者或資料庫的查詢之間。）

由於 queryid 雜湊值是在查詢的 post-parse-analysis 表示形式上計算的，因此反過來也是可能的：具有相同文字的查詢可能顯示為不同的條目，如果它們由於 search_path 設定不同等因素而具有不同的含義。

pg_stat_statements 的使用者可能希望使用 queryid（可能與 dbid 和 userid 結合使用）作為每個條目比其查詢文字更穩定可靠的識別符號。但是，重要的是要理解 queryid 雜湊值的穩定性僅有有限的保證。由於識別符號是從 post-parse-analysis 樹派生的，因此其值是諸如此表示形式中出現的內部物件識別符號等的函式。這會產生一些令人費解的影響。例如，pg_stat_statements 將認為兩個看起來相同的查詢是不同的，如果它們引用了在執行這兩個查詢之間被刪除並重新建立的函式。反之，如果一個表在查詢執行之間被刪除並重新建立，兩個看起來相同的查詢可能被認為是相同的。但是，如果對於其他類似的查詢，表的別名不同，則這些查詢將被視為不同的。雜湊過程對機器架構和其他平臺方面差異也很敏感。此外，不能安全地假設 queryid 在 PostgreSQL 的主要版本之間是穩定的。

基於物理 WAL 重放進行復制的兩個伺服器，對於同一個查詢，其 queryid 值應該是相同的。然而，邏輯複製方案並不保證副本在所有相關細節上保持一致，因此 queryid 不能作為跨多個邏輯副本累積成本的有用識別符號。如有疑問，建議進行直接測試。

通常，可以假定 queryid 值在 PostgreSQL 的次要版本釋出之間是穩定的，前提是例項在相同的機器架構上執行且目錄元資料細節匹配。相容性只有在萬不得已時才會破壞次要版本之間的相容性。

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

代表性查詢文字儲存在外部磁碟檔案中，不佔用共享記憶體。因此，即使非常長的查詢文字也可以成功儲存。但是，如果積累了大量長查詢文字，外部檔案可能會變得過大而無法管理。如果發生這種情況，作為一種恢復方法，pg_stat_statements 可能會選擇丟棄查詢文字，此時 pg_stat_statements 檢視中的所有現有條目將顯示 null 的 query 欄位，但與每個 queryid 相關的統計資訊將保留。如果發生這種情況，請考慮減小 pg_stat_statements.max 以防止再次發生。

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

pg_stat_statements 模組本身的統計資訊透過一個名為 pg_stat_statements_info 的檢視進行跟蹤和提供。此檢視僅包含一行。檢視的列在表 F.23 中顯示。

該模組需要與 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> 新增。