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

From Bruno Wolff III
Subject Re: index scan on =, but not < ?
Date
Msg-id 20050309052020.GB1569@wolff.to
Whole thread Raw
In response to Re: index scan on =, but not < ?  ("Jim C. Nasby" <decibel@decibel.org>)
Responses Re: index scan on =, but not < ?  ("Jim C. Nasby" <decibel@decibel.org>)
Re: index scan on =, but not < ?  (David Brown <time@bigpond.net.au>)
List pgsql-performance
On Tue, Mar 08, 2005 at 22:55:19 -0600,
  "Jim C. Nasby" <decibel@decibel.org> wrote:
> On Tue, Mar 08, 2005 at 10:38:21PM -0600, Bruno Wolff III wrote:
> > 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
>
> Shouldn't that be 50%?

No. When you are doing an index scan of a significant part of the table,
you will fetch some heap pages more than once. You will also be fetching
blocks out of order, so you will lose out on read ahead optimization
by the OS. This assumes that you don't get a lot of cache hits on the
help pages. If a significant portion of the table is cached, then the
trade off point will be at a higher percentage of the table.

pgsql-performance by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: index scan on =, but not < ?
Next
From: Josh Berkus
Date:
Subject: Re: Why would writes to pgsql_tmp bottleneck at 1mb/s?