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