PostgreSQL - 如果我同時執行多個查詢，在什麼情況下我會看到加速？在什麼情況下我會看到減速？
作為一個不是 DBA 的人，我謙虛地接近你們，我確信我的問題充滿了概念上的缺陷，並且“它取決於”地雷。我也很確定，所有選擇回答的人都會想要比我目前能夠提供的更多細節。
也就是說，我一般對以下情況感到好奇：
- 假設我有兩個重要的查詢。
- 查詢 1 平均需要 2 分鐘才能完成。
- 查詢 2 平均需要 5 分鐘才能完成。
如果我連續執行它們，一個接一個，我預計平均需要 7 分鐘才能完成。這合理嗎？
然而，更重要的是，如果我同時執行這兩個查詢會怎樣？同時進行兩個獨立的連接。
- 我希望在什麼條件下看到加速？（總時間 < 7 分鐘）
- 在什麼情況下，我預計會出現放緩？（總時間 > 7 分鐘）
現在，如果我同時執行 1,000 個重要查詢，我有一種預感，它會導致整體速度變慢。在這種情況下，瓶頸可能在哪裡？處理器？記憶體？驅動器？
同樣，我知道在不知道具體細節（我不知道）的情況下可能不可能準確地回答問題。我正在尋找一些一般指導方針，以便在提出以下問題時考慮：
- 在什麼情況下並發查詢會導致整體加速？
- 什麼情況下並發查詢會導致整體變慢？
如果我連續執行它們，一個接一個，我預計平均需要 7 分鐘才能完成。這合理嗎？
如果他們使用不相關的數據集，那麼可以。
如果它們共享一個數據集，並且第一個查詢的記憶體是冷的，並且查詢主要是 I/O 綁定的，那麼第二個查詢可能很快就會完成。在處理性能分析和查詢時序時，您需要考慮記憶體效果。
然而，更重要的是，如果我同時執行這兩個查詢會怎樣？同時進行兩個獨立的連接。
“這取決於”。
如果他們都使用同一個表的順序掃描，那麼在 PostgreSQL 中，由於它支持同步順序掃描，這將是一個巨大的性能提升。
如果它們共享相同的索引，那麼它們很可能會從彼此的讀入記憶體中受益。
如果它們是獨立的並且接觸不同的數據，那麼它們可能會爭奪 I/O 頻寬，在這種情況下，它們可能會花費與順序執行相同的時間。如果 I/O 子系統受益於並發性（更高的淨吞吐量和更多的客戶端），那麼總時間可能會更少。如果 I/O 子系統處理並發性不佳，那麼它們可能需要比順序執行更長的時間。或者它們可能根本不受 I/O 限制，在這種情況下，如果每個都有空閒 CPU，它們可以很好地執行，就好像另一個根本沒有執行一樣。
這在很大程度上取決於硬體和系統配置、數據集以及查詢本身。
現在，如果我同時執行 1,000 個重要查詢，我有一種預感，它會導致整體速度變慢。在這種情況下，瓶頸可能在哪裡？處理器？記憶體？驅動器？
是的，由於多種原因，這很可能會減慢速度。
- PostgreSQL 自己在程序間協調、事務和鎖管理、緩衝區管理等方面的成本。這可能是一個相當大的成本，而且 PostgreSQL 並不是真正為高客戶端數設計的——如果你排隊工作它會更好。
- 工作記憶體、記憶體等的競爭。
- 作業系統調度成本，因為它需要處理 1000 個競爭程序，它們都需要時間片。這些天非常小，現代作業系統具有快速調度程序。
- I/O 抖動。大多數 I/O 系統都有一個峰值性能的客戶端數量。有時它是 1，即最好只有一個客戶，但通常更高。有時性能再次下降到門檻值以上。有時它只是達到一個平台期。