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 по дате отправления: