PostgreSQL IO 成本邏輯

我一直在嘗試獲取 IO 成本編號，類似於 MS SQL 提供它的方式，但在 PostgreSQL 中。

我讀過 using EXPLAIN ANALYZE SELECT ...，輸出中會有 a cost，但成本對應於磁碟頁面獲取的數量。

但是，我不明白的是，當我執行我的範例時，即：

EXPLAIN ANALYZE SELECT * FROM table

結果是：

                                                    QUERY PLAN
---------------------------------------------------------------------------------------------------------------------
Seq Scan on 'table' (cost=0.00..14355.77 rows=652077 width=76) (actual time=0.050..40.275 rows=652077 loops=1)
Planning Time: 0.313 ms
Execution Time: 57.876 ms
(3 rows)

所以磁碟頁面獲取應該在 14355 左右。但是當我檢查表的大小時，即使包括 SELECT pg_size_pretty(pg_total_relation_size('table'));大小為 75MB 的索引。如果頁面為 8KB，那麼估計的磁碟頁面獲取應該是：

75 000 / 8 = 9375

那麼為什麼我使用時EXPLAIN會得到 14355 的成本？我錯過了什麼？

如手冊中所述，成本值的完整公式還包括按行計算的 CPU 部分

估計成本計算為（讀取的磁碟頁數 * seq_page_cost）+（掃描的行數 * cpu_tuple_cost）。預設情況下，seq_page_cost 為 1.0，cpu_tuple_cost 為 0.01

以上是 Seq Scan 的公式，因此使用了順序 I/O 的成本值。如果涉及隨機 I/O（例如索引掃描），則需要替換seq_page_cost為random_page_cost.

因此，在您的範例中，規劃器估計 652077 行，這導致增加的成本值約為 6520。將其添加到您對 9375 的估計結果為 15895，這比您的計劃顯示的要高一些，因此頁數可能會少一些。pg_class.relpages如果我沒記錯的話，估計的頁數來自。

老實說，我通常不太關心成本價值。在我看來，估計的行數和整體“計劃策略”更有趣。無論如何，大多數時間都在使用explain (analyze, buffers)，這樣我就可以輕鬆地確定計劃中最慢的操作。

引用自：https://dba.stackexchange.com/questions/301246