Re: index / sequential scan problem

От: Tom Lane
Тема: Re: index / sequential scan problem
Дата: ,
Msg-id: 23376.1058534698@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: index / sequential scan problem  (Dennis Björklund)
Ответы: Re: index / sequential scan problem  ("scott.marlowe")
Re: index / sequential scan problem  (Dennis Björklund)
Список: pgsql-performance

Скрыть дерево обсуждения

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 по дате сообщения:

От: Rod Taylor
Дата:
Сообщение: Re: Sanity check requested
От: Tom Lane
Дата:
Сообщение: Re: File systems (RE: Sanity check requested)