Re: Index Scans become Seq Scans after VACUUM ANALYSE

Поиск
Список
Период
Сортировка
От Christopher Kings-Lynne
Тема Re: Index Scans become Seq Scans after VACUUM ANALYSE
Дата
Msg-id GNELIHDDFBOCMGBFGEFOAECNCCAA.chriskl@familyhealth.com.au
обсуждение исходный текст
Ответ на Re: Index Scans become Seq Scans after VACUUM ANALYSE  (mlw <markw@mohawksoft.com>)
Список 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 по дате отправления:

Предыдущее
От: mlw
Дата:
Сообщение: Re: Index Scans become Seq Scans after VACUUM ANALYSE
Следующее
От: "Luis Alberto Amigo Navarro"
Дата:
Сообщение: Re: Index Scans become Seq Scans after VACUUM ANALYSE