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

From Tom Lane
Subject Re: Index Scans become Seq Scans after VACUUM ANALYSE
Date
Msg-id 5747.1019051733@sss.pgh.pa.us
Whole thread Raw
In response to Re: Index Scans become Seq Scans after VACUUM ANALYSE  (mlw <markw@mohawksoft.com>)
List pgsql-hackers
mlw <markw@mohawksoft.com> writes:
> 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.

I don't buy that argument at all.  It might be a unique index that he
must have in place for data integrity reasons.  It might be an index
that he needs for a *different* query.

If the table has more than one index available that might be usable
with a particular query, how does your argument help?  It doesn't.
We still have to trust to statistics and cost estimates.  So I intend
to proceed on the path of improving the estimator, not in the direction
of throwing it out in favor of rules-of-thumb.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Louis-David Mitterrand
Date:
Subject: huge runtime difference between 2 almost identical queries (was: Re: Index Scans become Seq Scans after VACUUM ANALYSE)
Next
From: Michael Loftis
Date:
Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE