Re: Index Scans become Seq Scans after VACUUM ANALYSE

Lincoln Yeoh wrote:
> 
> At 10:48 AM 4/18/02 -0400, mlw wrote:
> >Bruce Momjian wrote:
> > >
> > > Have you tried reducing 'random_page_cost' in postgresql.conf.  That
> > > should solve most of your problems if you would like more index scans.
> >
> >My random page cost is 1 :-)
> 
> What happens when you set random page cost to 1? Between an index scan of
> 50% of a table and a full table scan which would the optimizer pick? With
> it at 1, what percentage would be the switchover point?

I am no longer working on the project. Alas, the company is no more. Anyone
want to buy it? :-)

> I'm just wondering why not just use enable_seqscan=false for those
> problematic queries as a "hint"? Unless your query does need some seq scans
> as well?

I am the architect, thus only one of the developers. It was easier, and safer,
to make sure sequential scans did not get executed on a global basis. It would
be disastrous if the development version of the database did not do a
sequential scan, but the live version did. (This did happen to us once. Another
point of PostgreSQL vs Index frustration.)

The risk was minimal if a live query erroneously used an index, but the
consequenses, at least in our application, would be a 1~2 minute PostgreSQL
query.