类型: real
默认: 4
最低限度: 0
最大: 1.79769e+308
上下文: user
重新开始: false

设置规划器对一次非顺序获取磁盘页面的代价估计。默认值是 4.0。通过把表和索引放在一个特殊的表空间(要设置该表空间的同名参数)中可以覆盖这个值(见sql-altertablespace)。

减少这个值(相对于seq_page_cost)将导致系统更倾向于索引扫描;提高它将让索引扫描看起来相对更昂贵。你可以一起提高或降低两个值来改变磁盘 I/O 代价相对于 CPU 代价的重要性,后者由下列参数描述。

对磁盘存储的随机访问通常比顺序访问要贵不止四倍。但是,由于对磁盘的大部分随机访问(例如被索引的读取)都被假定在高速缓冲中进行,所以使用了一个较低的默认值(4.0)。默认值可以被想成把随机访问建模为比顺序访问慢 40 倍,而期望 90% 的随机读取会被缓存。

如果你相信 90% 的缓冲率对你的负载是一个不正确的假设,你可以增加 random_page_cost 来更好的反映随机存储读取的真正代价。相应地,如果你的数据可以完全放在高速缓存中(例如当数据库小于服务器总内存时),降低 random_page_cost 可能是合适的。为具有很低的随机读取代价的存储(例如固态驱动器)采用较低的 random_page_cost 值可能更好。

虽然允许你将random_page_cost设置的比 seq_page_cost小,但是物理上的实际情况并不受此影响。 然而当所有数据库都位于内存中时,两者设置为相等是非常合理的,因为 在此情况下,乱序抓取并不比顺序抓取开销更大。同样,在缓冲率很高的 数据库上,你应当相对于 CPU 开销同时降低这两个值,因为获取内存中 的页比通常情况下的开销小许多。 尽管系统可以是你把random_page_cost设置得小于seq_page_cost,但是实际上没有意义。不过,如果数据库被整个缓存在 RAM 中,将它们设置为相等是有意义的,因为在那种情况中不按顺序访问页面是没有惩罚值的。同样,在一个高度缓存化的数据库中,你应该相对于 CPU 参数降低这两个值,因为获取一个已经在 RAM 中的页面的代价要远小于通常情况下的代价。

建议 [EN]

Sets the ratio of seek to scan time for your database storage. Should not be altered unless you're using special storage (SSDs, high end SANs, etc.) where seek/scan ratios are actually different. If you need the database to favor indexes more, tune effective_cache_size and some of the cpu_* costs instead.

条评论