On Mon, May 31, 2010 at 3:55 PM, Tom Lane wrote:
> Jesper Krogh writes:
>> On 2010-05-30 20:34, Tom Lane wrote:
>>> Well, hmm, I really doubt that that represents reality either. A page
>>> access is by no means "free" even when the page is already in cache.
>>> I don't recall anyone suggesting
Scott Carey writes:
> It is still best to have random_page_cost to be slightly larger (~50%)
> than sequential_page_cost, because even when entirely in RAM,
> sequential reads are faster than random reads. Today's CPU's do
> memory prefetching on sequential access.
Do you have any actual evidenc
It is still best to have random_page_cost to be slightly larger (~50%) than
sequential_page_cost, because even when entirely in RAM, sequential reads are
faster than random reads. Today's CPU's do memory prefetching on sequential
access. Perhaps try something like 0.3 and 0.2, or half that. Y
Jesper Krogh writes:
> On 2010-05-30 20:34, Tom Lane wrote:
>> Well, hmm, I really doubt that that represents reality either. A page
>> access is by no means "free" even when the page is already in cache.
>> I don't recall anyone suggesting that you set these numbers to less
>> than perhaps 0.01.
On 2010-05-30 20:34, Tom Lane wrote:
Jesper Krogh writes:
testdb=# set seq_page_cost = 0.1;
SET
testdb=# set random_page_cost = 0.1;
SET
Well, hmm, I really doubt that that represents reality either. A page
access is by no means "free" even when the page is already in cache.
Jesper Krogh writes:
> testdb=# set seq_page_cost = 0.1;
> SET
> testdb=# set random_page_cost = 0.1;
> SET
Well, hmm, I really doubt that that represents reality either. A page
access is by no means "free" even when the page is already in cache.
I don't recall anyone suggesting that you
Hi.
I'm trying to get the planner to do sort of the correct thing
when choosing between index-scans on btree indices and
bitmap heap scans.
There has been several things going on in parallel. One
is that the statistics data is off:
http://thread.gmane.org/gmane.comp.db.postgresql.devel.general/1
