Re: Index Scans become Seq Scans after VACUUM ANALYSE

From: mlw <markw(at)mohawksoft(dot)com>
To: Oliver Elphick <olly(at)lfix(dot)co(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE
Date: 2002-04-17 06:15:46
Message-ID: 3CBD1312.558BA1C5@mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Oliver Elphick wrote:
>
> On Wed, 2002-04-17 at 06:51, mlw wrote:
> > I just think there is sufficient evidence to suggest that if a DBA creates an
> > index, there is strong evidence (better than statistics) that the index need be
> > used. In the event that an index exists, there is a strong indication that,
> > without overwhelming evidence, that the index should be used. You have admitted
> > that statistics suck, but the existence of an index must weight (heavily) on
> > the evaluation on whether or not to use an index.
>
> But indexes are not, for the most part, there because of a specific
> choice to have an index, but as the implementation of PRIMARY KEY and
> UNIQUE. Therefore the main part of your argument fails.

Let's talk about the primary key, that will not exhibit the borderline behavior
that we see. I have had first hand experience (and frustration) on PostgreSQL's
choice of using an index.

The primary key and UNIQUE constraint will only exhibit reduced performance on
REALLY small tables, in which case, the reduced performance is minimal if not
nonexistent.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Proctor 2002-04-17 06:22:14 Re: [SQL] 16 parameter limit
Previous Message Oliver Elphick 2002-04-17 06:07:21 Re: Index Scans become Seq Scans after VACUUM ANALYSE