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代价模型的示例分析"这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
