Re: reducing random_page_cost from 4 to 2 to force index scan

On Fri, May 13, 2011 at 4:13 PM, Josh Berkus <josh(at)agliodbs(dot)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