Re: Dissapearing indexes, what's that all about?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Dissapearing indexes, what's that all about?
Дата
Msg-id 731.986158103@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: Dissapearing indexes, what's that all about?  (Daniel ?erud <zilch@home.se>)
Список pgsql-general
Daniel ?erud <zilch@home.se> writes:
> Can't see the logic behind that though
> The jump in the b-tree must save about 5000 checks... half
> the table??

CPUs are fast.  Disks are slow.  If you think about CPU time rather
than disk accesses, you will usually draw the wrong conclusions.

Even more to the point, disks do not like random access.  A seqscan
can typically fetch four or more sequential blocks from disk in the
time it takes an indexscan to fetch one block on a random-access basis.

When you do the math it turns out seqscan wins unless you are fetching
just a small percentage of the rows.

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: another index question
Следующее
От: "ADBAAMD"
Дата:
Сообщение: Re: Ok, why isn't it using *this* index?