From: Tom Lane <tgl@sss.pgh.pa.us>
To: Scott Carey <scott@richrelevance.com>
Cc: Jesper Krogh <jesper@krogh.cc>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: planner costs in "warm cache" tests
Date: Tue, 01 Jun 2010 10:03:38 -0400
Message-ID: <2193.1275401018@sss.pgh.pa.us> (raw)
In-Reply-To: <31D5250B-7392-45DD-A234-8A5BBFF8F49A@richrelevance.com>
References: <4C02A342.40801@krogh.cc>
<14644.1275244491@sss.pgh.pa.us>
<4C040488.30906@krogh.cc>
<18310.1275335733@sss.pgh.pa.us>
<31D5250B-7392-45DD-A234-8A5BBFF8F49A@richrelevance.com>
Scott Carey <scott@richrelevance.com> writes:
> It is still best to have random_page_cost to be slightly larger (~50%)
> than sequential_page_cost, because even when entirely in RAM,
> sequential reads are faster than random reads. Today's CPU's do
> memory prefetching on sequential access.
Do you have any actual evidence of that? Because I don't believe it.
Neither PG nor any kernel that I've ever heard of makes any effort to
ensure that logically sequential blocks occupy physically sequential
buffers, so even if the CPU tries to do some prefetching, it's not
going to help at all.
Now, if the database isn't entirely cached, then indeed it's a good
idea to keep random_page_cost higher than seq_page_cost. But that's
because of the actual disk fetches, not anything that happens in RAM.
regards, tom lane
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: tgl@sss.pgh.pa.us, scott@richrelevance.com, jesper@krogh.cc
Subject: Re: planner costs in "warm cache" tests
In-Reply-To: <2193.1275401018@sss.pgh.pa.us>
* 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