PostgreSQL 代价模型

对于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 的，这点是需要注意的。