擴展能夠擴展，改變和推進Postgres的行為。怎么樣？通過掛鉤到低級Postgres API掛鉤。 橫向擴展Postgres的開源 Citus數據庫本身實現為 PostgreSQL擴展，它允許Citus保持與Postgres版本保持同步，而不像其他Postgres分支那樣落后。我之前已經寫過關于 各種類型的擴展，雖然我想深入了解最有用的Postgres擴展： pg_stat_statements。

你看，我剛從FOSDEM回來了。FOSDEM是布魯塞爾的年度免費和開源軟件會議，在此次活動中，我在PostgreSQL開發室中發表了關于Postgres擴展的演講 。截至當天結束時，在Postgres開發室中提出的一半以上的會談提到 pg_stat_statements：

Christophe Pettus在2019年FOSDEM的Postgres開發室的舞臺上，建議人們使用pg_stat_statements進行監控

圖片標題

如果您使用Postgres并且尚未使用 pg_stat_statements，則必須將其添加到工具箱中。即使你熟悉，也許值得重溫一下。

pg_stat_statements入門
Pg_stat_statements 是所謂的contrib擴展，可以在contrib PostgreSQL發行版的目錄中找到 。這意味著它已經與Postgres一起提供，您不必從源代碼或安裝包中構建它。如果尚未啟用，則可能必須為數據庫啟用它。這很簡單：

CREATE EXTENSION pg_stat_statements;
如果您在主要云提供商上運行 ，他們很可能已經為您安裝并啟用了它。

一旦 pg_stat_statements 安裝完畢，它就會開始默默地在封面下工作。Pg_stat_statements記錄針對您的數據庫運行的查詢，從中刪除多個變量，然后保存有關查詢的數據，例如它花了多長時間，以及底層讀/寫發生了什么。

注意：它不保存每個單獨的查詢，而是對它們進行參數化，然后保存聚合結果。

讓我們來看看如何使用幾個例子。假設我們執行以下查詢：

SELECT order_details .qty，

order_details .item_id，order_details .item_price

FROM order_details，

顧客

WHERE客戶.ID = ORDER_DETAILS .customer_id
與客戶.email = 'craig@citusdata.com'
它會將此查詢轉換為：

SELECT order_details .qty，

order_details .item_id，order_details .item_price

FROM order_details，

顧客

WHERE客戶.ID = ORDER_DETAILS .customer_id
和客戶.email = '？'
如果這是我的應用程序中的一個查詢，我經常執行以獲取零售訂單歷史記錄之類的訂單詳細信息，則不會保存為每個用戶運行此操作的頻率，而是保存聚合視圖。

看數據
從這里我們可以查詢原始數據， pg_stat_statements 我們會看到類似的東西：

選擇 *
來自 pg_stat_statements;

userid | 16384
dbid | 16388
查詢| select * from users where email = ？;
電話| 2
total_time | 0.000268
行| 2
shared_blks_hit | 16
shared_blks_read | 0
shared_blks_dirtied | 0
shared_blks_written | 0
local_blks_hit | 0
local_blks_read | 0
local_blks_dirtied | 0
local_blks_written | 0
...
使用pg_stat_statements提取數據分析
現在，這里有大量有價值的信息，作為一個更高級的用戶，有時它們都可以證明是有價值的。但即使沒有開始理解數據庫的內部，您也可以通過pg_stat_statements 某些方式查詢來獲得一些非常強大的見解 。通過查看 total_time 每個查詢調用查詢的次數和次數，我們可以非?？焖俚夭榭唇洺＿\行的查詢以及它們平均消耗的內容：

選擇
（TOTAL_TIME / 1000 / 60）作為總，
（total_time / calls）as avg，
詢問
來自 pg_stat_statements
ORDER BY 1個 DESC
限制 100 ;
您可以通過多種不同的方式對此進行過濾并對其進行排序，您可能只想關注運行超過1,000次的查詢。或者平均超過100毫秒的查詢。上面的查詢向我們顯示了對數據庫消耗的總時間（以分鐘為單位）以及以毫秒為單位的平均時間。通過上面的查詢，我會得到一些看起來像：

總計平均詢問

295.76	10.13	SELECT id FROM users ...
219.13	80.24	SELECT * FROM ...

（2排）
根據經驗，我知道當快速抓取記錄時，PostgreSQL應該能夠在1ms內 返回。鑒于此，我可以進行優化工作。在上面我看到將第一個查詢降低到1毫秒將是一個改進，但優化第二個查詢將為我的整個系統提供更大的性能提升。

特別說明：如果您正在構建 多租戶應用，則可能不希望pg_stat_statements參數化您的 tenant_id。為了解決這個問題，我們構建了citus_stat_statements來為您提供 每個租戶的見解。

如果你還沒有看過你的數據 pg_stat_statements - 甚至在過去的一個月 - 今天是一個美好的一天。它告訴你什么可以優化的地方？

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的最有用的Postgres扩展：pg_stat_statements的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。