Re: reducing random_page_cost from 4 to 2 to force index scan - Mailing list pgsql-performance

From Tom Lane
Subject Re: reducing random_page_cost from 4 to 2 to force index scan
Date
Msg-id 20553.1305574860@sss.pgh.pa.us
Whole thread Raw
In response to Re: reducing random_page_cost from 4 to 2 to force index scan  (Nathan Boley <npboley@gmail.com>)
List pgsql-performance
Nathan Boley <npboley@gmail.com> writes:
>> The accesses to an index are far more likely to be clustered than the
>> accesses to the underlying table, because the index is organized in a
>> way that's application-meaningful and the table not so much.

> So, to clarify, are you saying that if query were actually requesting
> rows uniformly random, then there would be no reason to suspect that
> index accesses would have hotspots? It seems like the index structure
> ( ie, the top node in b-trees ) could also get in the way.

The upper nodes would tend to stay in cache, yes, but we already assume
that in the index access cost model, in a kind of indirect way: the
model only considers leaf-page accesses in the first place ;-)

            regards, tom lane

pgsql-performance by date:

Previous
From: Nathan Boley
Date:
Subject: Re: reducing random_page_cost from 4 to 2 to force index scan
Next
From: Clemens Eisserer
Date:
Subject: hash semi join caused by "IN (select ...)"