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