Re: index scan on =, but not < ?

Поиск
Список
Период
Сортировка
От Bruno Wolff III
Тема Re: index scan on =, but not < ?
Дата
Msg-id 20050309052020.GB1569@wolff.to
обсуждение исходный текст
Ответ на Re: index scan on =, but not < ?  ("Jim C. Nasby" <decibel@decibel.org>)
Ответы Re: index scan on =, but not < ?  ("Jim C. Nasby" <decibel@decibel.org>)
Re: index scan on =, but not < ?  (David Brown <time@bigpond.net.au>)
Список pgsql-performance
On Tue, Mar 08, 2005 at 22:55:19 -0600,
  "Jim C. Nasby" <decibel@decibel.org> wrote:
> On Tue, Mar 08, 2005 at 10:38:21PM -0600, Bruno Wolff III wrote:
> > Not exactly. If the number of rows to be examined is on the order of 5%
> > of the table, an index scan will probably be slower than a sequential
> > scan. The visibility issue makes index scans slower in the case that
>
> Shouldn't that be 50%?

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.

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

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: index scan on =, but not < ?
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Why would writes to pgsql_tmp bottleneck at 1mb/s?