pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedrandom_page_cost configuration parameter
4+ messages / 3 participants
[nested] [flat]
* random_page_cost configuration parameter
@ 2021-12-28 10:55 Mathias Kunter <mathiaskunter@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Mathias Kunter @ 2021-12-28 10:55 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: random_page_cost configuration parameter
@ 2021-12-28 16:03 Tom Lane <tgl@sss.pgh.pa.us>
parent: Mathias Kunter <mathiaskunter@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2021-12-28 16:03 UTC (permalink / raw)
To: Mathias Kunter <mathiaskunter@gmail.com>; +Cc: pgsql-docs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: random_page_cost configuration parameter
@ 2022-01-05 18:27 Mathias Kunter <mathiaskunter@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 4+ messages in thread
From: Mathias Kunter @ 2022-01-05 18:27 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-docs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: random_page_cost configuration parameter
@ 2022-01-07 21:52 Bruce Momjian <bruce@momjian.us>
parent: Mathias Kunter <mathiaskunter@gmail.com>
0 siblings, 0 replies; 4+ messages in thread
From: Bruce Momjian @ 2022-01-07 21:52 UTC (permalink / raw)
To: Mathias Kunter <mathiaskunter@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-docs@lists.postgresql.org
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.
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2022-01-07 21:52 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-12-28 10:55 random_page_cost configuration parameter Mathias Kunter <mathiaskunter@gmail.com>
2021-12-28 16:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-01-05 18:27 ` Mathias Kunter <mathiaskunter@gmail.com>
2022-01-07 21:52 ` Bruce Momjian <bruce@momjian.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox