Re: reducing random_page_cost from 4 to 2 to force index scan

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: reducing random_page_cost from 4 to 2 to force index scan
Дата
Msg-id 20553.1305574860@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: reducing random_page_cost from 4 to 2 to force index scan  (Nathan Boley <npboley@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Nathan Boley
Дата:
Сообщение: Re: reducing random_page_cost from 4 to 2 to force index scan
Следующее
От: Clemens Eisserer
Дата:
Сообщение: hash semi join caused by "IN (select ...)"