Re: reducing random_page_cost from 4 to 2 to force index scan - Mailing list pgsql-performance

From Robert Haas
Subject Re: reducing random_page_cost from 4 to 2 to force index scan
Date
Msg-id BANLkTi=BTJ56m-OozcD8fH2kkHOqmA4fHA@mail.gmail.com
Whole thread Raw
In response to Re: reducing random_page_cost from 4 to 2 to force index scan  (Josh Berkus <josh@agliodbs.com>)
Responses Re: reducing random_page_cost from 4 to 2 to force index scan
List pgsql-performance
On Fri, May 13, 2011 at 4:13 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Instead, we should be fixing the formulas these are based on and leaving
> RPC alone.
>
> For any data page, there are actually four costs associated with each
> tuple lookup, per:

All true.  I suspect that in practice the different between random and
sequential memory page costs is small enough to be ignorable, although
of course I might be wrong.  I've never seen a database that was fully
cached in memory where it was necessary to set
random_page_cost>seq_page_cost to get good plans -- no doubt partly
because even if the pages were consecutive on disk, there's no reason
to suppose they would be so in memory, and we certainly wouldn't know
one way or the other at planning time.   But I agree we should add a
cached_page_cost as part of all this.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-performance by date:

Previous
From: John Rouillard
Date:
Subject: Using pgiosim realistically
Next
From: Robert Haas
Date:
Subject: Re: Query improvement