From: Cédric Villemain <cedric.villemain.debian@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Nathan Boley <npboley@gmail.com>
Cc: Claudio Freire <klaussfreire@gmail.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Ogden <lists@darkstatic.com>
Cc: Tomas Vondra <tv@fuzzy.cz>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance
Date: Thu, 14 Apr 2011 13:29:35 +0200
Message-ID: <BANLkTimqy13x1D7Bm-Xf6CjRgWWdv7nj7g@mail.gmail.com> (raw)
In-Reply-To: <1809.1302739389@sss.pgh.pa.us>
References: <DF2D5436-117C-4D02-9B3C-A55723B7DDE1@darkstatic.com>
<20110412171855.GA14292@tux>
<FC3A3A2B-3ECB-41BA-8F94-356D6FED3695@darkstatic.com>
<4DA496FA.3070908@fuzzy.cz>
<8F22D592-23C1-4A3C-94A5-48363332ADD3@darkstatic.com>
<4DA4BFA2.5060601@fuzzy.cz>
<B93DFBBB-DA56-4044-A508-0B7E4A2CFD28@darkstatic.com>
<4DA4D40A.4010200@fuzzy.cz>
<A0B9339E-9D58-4842-A206-050B773360B6@darkstatic.com>
<4DA56DA8020000250003C783@gw.wicourts.gov>
<BANLkTinJqXqErAtQg--1MOaw2LJNFZmwOg@mail.gmail.com>
<BANLkTimyWkoX8Dj=4CKAjhY82ibru-An7g@mail.gmail.com>
<1809.1302739389@sss.pgh.pa.us>
2011/4/14 Tom Lane <tgl@sss.pgh.pa.us>:
> Nathan Boley <npboley@gmail.com> writes:
>> FWIW, awhile ago I wrote a simple script to measure this and found
>> that the *actual* random_page / seq_page cost ratio was much higher
>> than 4/1.
>
> That 4:1 ratio is based on some rather extensive experimentation that
> I did back in 2000. In the interim, disk transfer rates have improved
> quite a lot more than disk seek times have, and the CPU cost to process
> a page's worth of data has also improved compared to the seek time.
> So yeah, you'd likely get a higher number if you redid those experiments
> on modern hardware (at least assuming it was rotating media and not SSD).
> On the other hand, the effects of caching push the numbers in the other
> direction, and modern machines also have a lot more RAM to cache in than
> was typical ten years ago. I'm not sure how much point there is in
> trying to improve the default number in the abstract --- we'd really
> need to have a more robust model of cache effects before I'd trust any
> automatic tuning procedure to set the value for me.
Well, at spare time, I am doing some POC with "ANALYZE OSCACHE
relation;", pg stats are updated accordingly with new data ( it is not
finish yet) : at least the percentage in OS cache, maybe the number of
groups in cache and/or the distribution.
Anyway the idea is to allow the planner to use random and seq page
cost to be applyed on the part not-in-cache, without replacing the
algo using effective_cache_size. The planner may have one other GUC
like 'mem_page_cost' to set a cost on access from cache and use it
while estinating the cost...
Side effect is that random page cost and seq page cost should be more
stable and easiest to set based on a script because they won't have
the mixed sources of disk/memory, only the disk acces cost. (if
ANALYZE OSCACHE is good enough)
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: cedric.villemain.debian@gmail.com, tgl@sss.pgh.pa.us, npboley@gmail.com, klaussfreire@gmail.com, Kevin.Grittner@wicourts.gov, lists@darkstatic.com, tv@fuzzy.cz
Subject: Re: Performance
In-Reply-To: <BANLkTimqy13x1D7Bm-Xf6CjRgWWdv7nj7g@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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