Re: index / sequential scan problem - Mailing list pgsql-performance

From scott.marlowe
Subject Re: index / sequential scan problem
Date
Msg-id Pine.LNX.4.33.0307180808530.1889-100000@css120.ihs.com
Whole thread Raw
In response to Re: index / sequential scan problem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Fri, 18 Jul 2003, Tom Lane wrote:

> =?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <db@zigo.dhs.org> writes:
> > On Fri, 18 Jul 2003, Fabian Kreitner wrote:
> >> Adjusting the cpu_tuple_cost to 0.042 got the planner to choose the index.
>
> > Doesn't sound very good and it will most likely make other queries slower.
>
> Seems like a reasonable approach to me --- certainly better than setting
> random_page_cost to physically nonsensical values.
>
> In a fully-cached situation it's entirely reasonable to inflate the
> various cpu_xxx costs, since by assumption you are not paying the normal
> price of physical disk I/O.  Fetching a page from kernel buffer cache
> is certainly cheaper than getting it off the disk.  But the CPU costs
> involved in processing the page contents don't change.  Since our cost
> unit is defined as 1.0 = one sequential page fetch, you have to increase
> the cpu_xxx numbers instead of reducing the I/O cost estimate.
>
> I would recommend inflating all the cpu_xxx costs by the same factor,
> unless you have evidence that they are wrong in relation to each other.

And don't forget to set effective_cache_size.  It's the one I missed for
the longest when I started.


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Clearing rows periodically
Next
From: "Nick Fankhauser"
Date:
Subject: File systems (RE: Sanity check requested)