Re: index / sequential scan problem

=?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.

regards, tom lane