Re: PG8.2.1 choosing slow seqscan over idx scan

Поиск
Список
Период
Сортировка
От Jeremy Haile
Тема Re: PG8.2.1 choosing slow seqscan over idx scan
Дата
Msg-id 1168986053.16393.1169598917@webmail.messagingengine.com
обсуждение исходный текст
Ответ на Re: PG8.2.1 choosing slow seqscan over idx scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: PG8.2.1 choosing slow seqscan over idx scan  ("Chad Wagner" <chad.wagner@gmail.com>)
Список pgsql-performance
Thanks Tom!  Reducing random_page_cost to 2 did the trick for this
query.  It now favors the index scan.

Even if this is a cached situation, I wouldn't expect a difference of 3
min vs 3 seconds.

Even if unrelated, do you think disk fragmentation would have negative
effects?  Is it worth trying to defragment the drive on a regular basis
in Windows?

Jeremy Haile


On Tue, 16 Jan 2007 16:39:07 -0500, "Tom Lane" <tgl@sss.pgh.pa.us> said:
> "Jeremy Haile" <jhaile@fastmail.fm> writes:
> > Running PostgreSQL 8.2.1 on Win32.   The query planner is choosing a seq
> > scan over index scan even though index scan is faster (as shown by
> > disabling seqscan).  Table is recently analyzed and row count estimates
> > seem to be in the ballpark.
>
> Try reducing random_page_cost a bit.  Keep in mind that you are probably
> measuring a fully-cached situation here, if you repeated the test case.
> If your database fits into memory reasonably well then that's fine and
> you want to optimize for that case ... but otherwise you may find
> yourself pessimizing the actual behavior.
>
>             regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PG8.2.1 choosing slow seqscan over idx scan
Следующее
От: "Chad Wagner"
Дата:
Сообщение: Re: PG8.2.1 choosing slow seqscan over idx scan