PostgreSQL代價模型的示例分析

這篇文章將為大家詳細講解有關PostgreSQL代價模型的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

作為目前可以替代oracle的主力數據庫，了解POSTGRESQL 的代價模型，有利于在分析SQL 語句和 優化SQL 語句時明白可能存在的問題根源和解決方法。

對于ORACLE ，SQL SERVER 這樣的數據庫的代價模型一般是不會透露給外部的，所以我們看到一些COST 也是一頭霧水，摸不清頭腦。

PostgreSQL 在代價模型上是開放的，有利于運維以及開發人員理解性能較差的查詢發生在哪里。

首先我們先分析一下可能存在的  cost 的點在哪里, 以下是一個計劃樹的大致順序和名稱

1  Seq Scan

2  sort

3 Materialize

4 index scan

5 Merge left join 

6 group aggregate

7 hashaggregate

設計POSTGRESQL 的 cost model

1  Seq_page_cost  = Cs

2  random_page_cost = Cr

3 cpu_tuple_cost = Ct

4 cpu_index_tuple_cost = Ci

5 cpu_operator_cost = Co

6 number of disk pages fetched sequentially  = Ns

7 number of disk pages fetched randomly

8 number of tuples proessed

9 number of index entries processed during an index scan

10 number of operations performed

一個總體的 cost  大致由

C = Ns * Cs + Nr * Cr + Nt * Ct + Ni* Ci + No*Co

同時我們需要知道 cost parameters 的 參數的默認值

cs  1.00

cr  4.00

ct 1.00e-2

ci  5.00e-3

co 2.50e-3

大體上我們可以知道一個 COST 的計算是通過 查詢的所需的步驟， 步驟的復雜度，CPU 和 I/O 并行度， 鎖查詢的記錄的relation_size 等等組成， 通過這樣的計算，多鐘查詢的方式，最終的值比較，得出那個是好的查詢 ，那個就被廢棄了。

下面我們做一個簡單的分析，下面是每一個方式的默認的消耗值

我們來嘗試計算下一個查詢的 cost ,大家看下面的圖

估計會有兩個疑問，1770 從哪里來的， 為什么是 3600000

1 1770 是通過整體數據，來計算出來的tuple 數據元， 另一個3600000 是table's 記錄數的行數。

大家可以看到計算出的數字就是 Query plan 的數字。

一般來說簡單的cost 通過人工來計算還是比較簡單的，但是如果復雜的例如并行，索引，等等就比較麻煩了。人工算起來會比價麻煩

同時還有一點，在計算I/O的 costing 的時候，需要注意，如果在使用索引的情況下  隨機讀 random_page_cost默認值是 4 ，但如果你的磁盤是 SSD的情況下，則隨機讀和順序讀的差距會很小，被忽略，所以 random_page_cost 的值是可以設置為1 的，這點是需要注意的。

關于“PostgreSQL代價模型的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。