random_page_cost configuration parameter

Started by Mathias Kunterover 4 years ago4 messagesdocs
Jump to latest
#1Mathias Kunter
mathiaskunter@gmail.com

Hello all,

the documentation of the random_page_cost configuration parameter says:

Although the system will let you set random_page_cost to less than
seq_page_cost, it is not physically sensible to do so.

Source:
https://www.postgresql.org/docs/current/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS

However, I don't think this statement is true. Consider the situation
where the randomly fetched pages are mostly (or even entirely) cached in
RAM, but where the sequentially fetched pages must be mostly read from
disk. An example for such a scenario is a database system which uses
RAM-cached indices.

Such a database system would be best modeled with random_page_cost <
seq_page_cost. Please correct me if I'm wrong.

Best regards
Mathias Kunter

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Mathias Kunter (#1)
Re: random_page_cost configuration parameter

Mathias Kunter <mathiaskunter@gmail.com> writes:

the documentation of the random_page_cost configuration parameter says:

Although the system will let you set random_page_cost to less than
seq_page_cost, it is not physically sensible to do so.

However, I don't think this statement is true. Consider the situation
where the randomly fetched pages are mostly (or even entirely) cached in
RAM, but where the sequentially fetched pages must be mostly read from
disk. An example for such a scenario is a database system which uses
RAM-cached indices.

I think fooling with effective_cache_size is a better way to model
that situation.

regards, tom lane

#3Mathias Kunter
mathiaskunter@gmail.com
In reply to: Tom Lane (#2)
Re: random_page_cost configuration parameter

Am 28.12.21 um 17:03 schrieb Tom Lane:

Mathias Kunter <mathiaskunter@gmail.com> writes:

Consider the situation
where the randomly fetched pages are mostly (or even entirely) cached in
RAM, but where the sequentially fetched pages must be mostly read from
disk. An example for such a scenario is a database system which uses
RAM-cached indices.

I think fooling with effective_cache_size is a better way to model
that situation.

The default value of effective_cache_size is 4 GB. Which value should
be used instead on a system which only has 4 GB of total RAM, but still
uses RAM-cached indices?

Thank you very much for the clarification!

Best regards
Mathias Kunter

#4Bruce Momjian
bruce@momjian.us
In reply to: Mathias Kunter (#3)
Re: random_page_cost configuration parameter

On Wed, Jan 5, 2022 at 07:27:55PM +0100, Mathias Kunter wrote:

Am 28.12.21 um 17:03 schrieb Tom Lane:

Mathias Kunter <mathiaskunter@gmail.com> writes:

Consider the situation
where the randomly fetched pages are mostly (or even entirely) cached in
RAM, but where the sequentially fetched pages must be mostly read from
disk. An example for such a scenario is a database system which uses
RAM-cached indices.

I think fooling with effective_cache_size is a better way to model
that situation.

The default value of effective_cache_size is 4 GB. Which value should be
used instead on a system which only has 4 GB of total RAM, but still uses
RAM-cached indices?

This might help:

https://momjian.us/main/blogs/pgblog/2012.html#May_4_2012

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.