Re: index on large table

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: index on large table
Дата
Msg-id 200203132051.g2DKphU12227@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: index on large table  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Tom Lane wrote:
> >> "explain select * from events order by oid limit 10 offset 1000000"
> >> NOTICE:  QUERY PLAN:
> >> Limit  (cost=424863.54..424863.54 rows=10 width=130)
> >> ->  Sort  (cost=424863.54..424863.54 rows=1025245 width=130)
> >> ->  Seq Scan on events  (cost=0.00..35645.45 rows=1025245 width=130)
> >>
> >> Bummer. This is very slow again, sequential scan again. Why the index is
> >> not used for this query? Use of index would make it very fast!
>
> Not necessarily.  Using the index for this would require fetching
> 1000000+10 values in the indexscan (and throwing away all but 10).
>
> The planner is counting on its fingers and guessing that the sort
> is faster.  It might or might not be right about that (have you
> compared timings?) but certainly the index method won't be
> instantaneous.

This question is being asked a lot. I hope my new FAQ item 4.8 wording
helps, but it will take time for people to read the new version.  I will
add it to 7.2.X CVS.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Query planner problem
Следующее
От: "Jeffrey W. Baker"
Дата:
Сообщение: Re: more about pg_toast growth