Re: Index Scans become Seq Scans after VACUUM ANALYSE

From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "mlw" <markw(at)mohawksoft(dot)com>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Louis-David Mitterrand" <vindex(at)apartia(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE
Date: 2002-04-17 06:53:48
Message-ID: GNELIHDDFBOCMGBFGEFOAECNCCAA.chriskl@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> If the DBA notices that there is a problem with a query, he adds
> an index, he
> notices that there is no difference, then he notices that
> PostgreSQL is not
> using his index. First and foremost he gets mad at PostgreSQL for
> not using his
> index. If PostgreSQL decided to use an index which increases
> execution time,
> the DBA would delete the index. If PostgreSQL does not use an
> index, he has to
> modify the posgresql.conf file, which disallows PostgreSQL from
> using an index
> when it would be a clear loser.
>
> My assertion is this: "If a DBA creates an index, he has a basis for his
> actions."

What about a GUC parameter

prefer_indexes = yes/no

Which when set to yes, assumes the DBA knows what he's doing. Unless the
table is really small, in which case it'll still scan.

But then again, if the dba sets up a huge table (million rows) and does a
select over an indexed field that will return 1/6 of all the rows, then
postgres would be nuts to use the index...

But then if the DBA does a query to return just 1 of the rows, postgres
would be nuts NOT to use the index. How do you handle this situation?

Chris

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Luis Alberto Amigo Navarro 2002-04-17 07:30:08 Re: Index Scans become Seq Scans after VACUUM ANALYSE
Previous Message Hannu Krosing 2002-04-17 06:36:09 Re: Index Scans become Seq Scans after VACUUM ANALYSE