Re: index / sequential scan problem

From: Tom Lane
Subject: Re: index / sequential scan problem
Date: ,
Msg-id: 23376.1058534698@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: index / sequential scan problem  (Dennis Björklund)
Responses: Re: index / sequential scan problem  ("scott.marlowe")
Re: index / sequential scan problem  (Dennis Björklund)
List: pgsql-performance

Tree view

index / sequential scan problem  (Fabian Kreitner, )
 Re: index / sequential scan problem  ("Shridhar Daithankar", )
  Re: index / sequential scan problem  (Fabian Kreitner, )
   Re: index / sequential scan problem  ("Shridhar Daithankar", )
 Re: index / sequential scan problem  (Paul Thomas, )
  Re: index / sequential scan problem  (Fabian Kreitner, )
   Re: index / sequential scan problem  (Paul Thomas, )
    Re: index / sequential scan problem  (Fabian Kreitner, )
     Re: index / sequential scan problem  ("Shridhar Daithankar", )
     Re: index / sequential scan problem  (Jord Tanner, )
     Re: index / sequential scan problem  (Paul Thomas, )
      Re: index / sequential scan problem  (Tom Lane, )
   Re: index / sequential scan problem  (Tom Lane, )
    Re: index / sequential scan problem  (Fabian Kreitner, )
     Re: index / sequential scan problem  (Fabian Kreitner, )
      Re: index / sequential scan problem  (Dennis Björklund, )
       Re: index / sequential scan problem  (Tom Lane, )
        Re: index / sequential scan problem  ("scott.marlowe", )
        Re: index / sequential scan problem  (Dennis Björklund, )

=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <> 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


pgsql-performance by date:

From: Rod Taylor
Date:
Subject: Re: Sanity check requested
From: Tom Lane
Date:
Subject: Re: File systems (RE: Sanity check requested)