Re: index scan on =, but not < ?

From: David Brown <time(at)bigpond(dot)net(dot)au>
To: Bruno Wolff III <bruno(at)wolff(dot)to>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: index scan on =, but not < ?
Date: 2005-03-10 00:06:23
Message-ID: 422F8F7F.2040505@bigpond.net.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Assuming your system isn't starved for memory, shouldn't repeated page
fetches be hitting the cache?

I've also wondered about the conventional wisdom that read ahead doesn't
help random reads. I may well be missing something, but *if* the OS has
enough memory to cache most of the table, surely read ahead will still
work to your advantage?

Bruno Wolff III wrote:

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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message David Brown 2005-03-10 00:24:46 Re: index scan on =, but not < ?
Previous Message Russell Smith 2005-03-09 22:08:32 Re: Help trying to tune query that executes 40x slower than in SqlServer