Re: Instances where enable_seqscan = false is good

On Tue, 2007-09-04 at 05:15 +0100, Gregory Stark wrote:
> "Ow Mun Heng" <Ow(dot)Mun(dot)Heng(at)wdc(dot)com> writes:
>
> > On Mon, 2007-09-03 at 11:31 +0100, Gregory Stark wrote:
> >> "Ow Mun Heng" <Ow(dot)Mun(dot)Heng(at)wdc(dot)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.
exactly, might as well use enable_seqscan=false. So it's still default
at 4

> 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?)

Have not changed anything in that area. Question is.. Do I need to? or
should I try out something just to see how it is?
(any) Recommendations would be good.