當您繪製一段時間內的輸送量圖表，並修改另一個變數時，通常會看到輸送量增加，直到輸送量達到資源耗盡的程度為止。
下圖顯示典型的輸送量調整圖。隨著用戶端數量增加，工作負載和輸送量也會增加，直到所有資源耗盡為止。
理想情況下，系統負載加倍時，輸送量也應加倍。實際上，資源會發生爭用情形，導致總處理量增幅較小。資源耗盡或爭用會導致輸送量趨緩，甚至降低。如果您要盡量提高輸送量，這是找出關鍵點的重要步驟，因為這會引導您調整應用程式或資料庫系統，以提高輸送量。
輸送量趨緩或下降的常見原因包括：
- 資料庫伺服器上的 CPU 資源耗盡
- 用戶端 CPU 資源耗盡，因此不會再將工作傳送至資料庫伺服器
- 資料庫鎖定爭用
- 資料超過 Postgres 緩衝區集區大小時的 I/O 等待時間
- 因儲存引擎使用率而導致的 I/O 等待時間
- 網路頻寬瓶頸會將資料傳回用戶端
延遲時間和輸送量成反比。延遲時間越長，總處理量就越低。直覺上來說，這很合理。當瓶頸開始成形時，作業會開始耗費更多時間，且系統每秒執行的作業會減少。
延遲比例圖表顯示系統負載增加時，延遲的變化情形。延遲時間會維持相對穩定，直到資源爭用導致摩擦為止。這條曲線的轉折點通常對應於輸送量縮放圖中輸送量曲線的平緩處。
以直方圖形式評估延遲時間也很實用。在這個表示法中，我們會將延遲時間分組，並計算每個組別中的要求數量。
這個延遲時間直方圖顯示，大多數要求都在 100 毫秒內完成，且延遲時間超過 100 毫秒。瞭解延遲時間較長的尾端要求原因，有助於說明應用程式效能的變化。延遲時間增加的長尾效應，與一般延遲時間縮放圖中延遲時間增加，以及輸送量圖趨於平緩的情況相符。
如果應用程式有多種模態，延遲直方圖就非常實用。模式是一組正常的運作條件。舉例來說，應用程式大部分時間都是存取緩衝區快取中的網頁。應用程式通常會更新現有資料列，但可能有多種模式。有時應用程式會從儲存空間擷取網頁、插入新資料列，或是發生鎖定爭用情形。
如果應用程式在一段時間內遇到這些不同的運作模式，延遲時間直方圖就會顯示這些多種模式。
這張圖顯示典型的雙峰直方圖，其中大部分要求都在 100 毫秒內處理完畢，但另一個要求叢集則需要 401 到 500 毫秒。瞭解第二種模態的原因，有助於提升應用程式的效能。也可以有超過兩種模式。
第二種模式可能是因為正常的資料庫作業、異質基礎架構和拓撲，或是應用程式行為。以下列舉幾個例子：
- 大部分資料存取作業都是從 PostgreSQL 緩衝區集區進行，但有些作業是從儲存空間進行
- 部分用戶端連線至資料庫伺服器的網路延遲時間不同
- 應用程式邏輯會根據輸入內容或一天中的時間執行不同作業。
- 偶發的鎖定爭用
- 用戶端活動量暴增