| From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
|---|---|
| To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
| Cc: | Rick Schumeyer <rschumeyer(at)ieee(dot)org>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: index scan on =, but not < ? |
| Date: | 2005-03-09 05:20:20 |
| Message-ID: | 20050309052020.GB1569@wolff.to |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Mar 08, 2005 at 22:55:19 -0600,
"Jim C. Nasby" <decibel(at)decibel(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2005-03-09 07:00:46 | Re: Why would writes to pgsql_tmp bottleneck at 1mb/s? |
| Previous Message | Jim C. Nasby | 2005-03-09 04:55:19 | Re: index scan on =, but not < ? |