Re: Index Scans become Seq Scans after VACUUM ANALYSE

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Michael Loftis <mloftis(at)wgops(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE
Date: 2002-04-17 00:47:08
Message-ID: 20020416174111.O53171-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 16 Apr 2002, Michael Loftis wrote:

> I know I know, replying to myself is bad and probably means I'm going
> insane but thought of one other thing...
>
> Realistically the system should choos *ANY* index over a sequential
> table scan. Above a fairly low number of records any indexed query
> should be much faster than a seqscan. Am I right, or did I miss
> something? (wouldn't be the first time I missed something)... Right

Because the validity information is stored with the row and not the index
you have to read rows for any potential hit in the index. Depending on
the clustering of the table, the width of the rows and the percentage of
the table being hit by the scan (or estimated to be hit) you may read
most or all of the table as well as the index and be paying a penalty for
doing it randomly as opposed to be sequentially. IIRC, there are some
settings in the configuration that let you play around with the relative
costs the estimator uses (the random page cost and cpu costs for dealing
with index entries and such).

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2002-04-17 02:09:29 Re: multibyte support by default
Previous Message Michael Loftis 2002-04-17 00:31:13 Re: Index Scans become Seq Scans after VACUUM ANALYSE