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