Re: index scan on =, but not < ? - Mailing list pgsql-performance

From Bruno Wolff III
Subject Re: index scan on =, but not < ?
Date
Msg-id 20050309043821.GA1569@wolff.to
Whole thread Raw
In response to index scan on =, but not < ?  ("Rick Schumeyer" <rschumeyer@ieee.org>)
Responses Re: index scan on =, but not < ?  ("Jim C. Nasby" <decibel@decibel.org>)
List pgsql-performance
On Tue, Mar 08, 2005 at 13:35:53 -0500,
  Rick Schumeyer <rschumeyer@ieee.org> wrote:
> I have two index questions.  The first is about an issue that has been
> recently discussed,
>
> and I just wanted to be sure of my understanding.  Functions like count(),
> max(), etc. will
>
> use sequential scans instead of index scans because the index doesn't know
> which rows
>
> are actually visible.is this correct?

Not exactly. If the number of rows to be examined is on the order of 5%
of the table, an index scan will probably be slower than a sequential
scan. The visibility issue makes index scans slower in the case that
the only columns of interest are in the index.
Another issue is that max could in theory use an index, but there isn't
a mechanism for Postgres to know how to do this in general for aggregates
where it is possible. There have been discussions in the past about
how this could be done, but no one has done it yet.

pgsql-performance by date:

Previous
From: Karim Nassar
Date:
Subject: Re: 64bit Opteron multi drive raid. Help with best config
Next
From: Tom Lane
Date:
Subject: Re: Why would writes to pgsql_tmp bottleneck at 1mb/s?