Re: index / sequential scan problem

On Fri, 18 Jul 2003, Tom Lane wrote:

> =?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <db(at)zigo(dot)dhs(dot)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.