Re: Instances where enable_seqscan = false is good

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Instances where enable_seqscan = false is good
Дата
Msg-id 87y7fngj6q.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: Instances where enable_seqscan = false is good  (Ow Mun Heng <Ow.Mun.Heng@wdc.com>)
Ответы Re: Instances where enable_seqscan = false is good  (Ow Mun Heng <Ow.Mun.Heng@wdc.com>)
Список pgsql-general
"Ow Mun Heng" <Ow.Mun.Heng@wdc.com> writes:

> On Mon, 2007-09-03 at 11:31 +0100, Gregory Stark wrote:
>> "Ow Mun Heng" <Ow.Mun.Heng@wdc.com> writes:
>> >
>> > How can I persuade PG to use the index w/o resorting to setting seqscan
>> > = false
>>
>> The usual knob to fiddle with is random_page_cost. If your database fits
>> mostly in memory you may want to turn it down from the default of 4 to
>> something closer to 1.
>
> I tried down to 0.4 before it resorted to using the index. The DB
> shouldn't fit into memory (I think) that table alone has ~8million rows
> at ~1.5G size

Values under 1 are nonsensical. Basically being as low as 1 means you're
telling the database that a random access i/o takes the same amount of time as
a sequential i/o. (Actually we have sequential_page_cost now so I guess
instead of "1" I should say "the same as sequential_page_cost" but I'm
assuming you haven't modified sequential_page_cost from the default of 1 have
you?)

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

В списке pgsql-general по дате отправления:

Предыдущее
От: "Mikko Partio"
Дата:
Сообщение: Re: Symlinking (specific) tables to different Drives
Следующее
От: Ow Mun Heng
Дата:
Сообщение: Re: Instances where enable_seqscan = false is good