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