Re: Index Scans become Seq Scans after VACUUM ANALYSE - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: Index Scans become Seq Scans after VACUUM ANALYSE
Date
Msg-id GNELIHDDFBOCMGBFGEFOAECNCCAA.chriskl@familyhealth.com.au
Whole thread Raw
In response to Re: Index Scans become Seq Scans after VACUUM ANALYSE  (mlw <markw@mohawksoft.com>)
List 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



pgsql-hackers by date:

Previous
From: mlw
Date:
Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE
Next
From: "Luis Alberto Amigo Navarro"
Date:
Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE