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