Re: GiST index performance

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: GiST index performance
Дата
Msg-id
26037.1239904355@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
GiST index performance Matthew Wakeling <matthew@flymine.org>
Re: GiST index performance "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: GiST index performance Tom Lane <tgl@sss.pgh.pa.us>
Re: GiST index performance Matthew Wakeling <matthew@flymine.org>
Re: GiST index performance Tom Lane <tgl@sss.pgh.pa.us>
Re: GiST index performance Matthew Wakeling <matthew@flymine.org>
Re: GiST index performance Matthew Wakeling <matthew@flymine.org>
Re: GiST index performance Matthew Wakeling <matthew@flymine.org>
Re: GiST index performance Tom Lane <tgl@sss.pgh.pa.us>
Re: GiST index performance Matthew Wakeling <matthew@flymine.org>
Re: GiST index performance dforum <dforums@vieonet.com>
Re: GiST index performance Tom Lane <tgl@sss.pgh.pa.us>
Re: GiST index performance Craig Ringer <craig@postnewspapers.com.au>
Re: GiST index performance Matthew Wakeling <matthew@flymine.org>
dforum  writes:
> If you analyse query plan, you see that most of the time are lost during 
> sequencial scan, and you have 2 seq scan.

I think you missed the loops count.

>>          ->  Index Scan using location_object_start_gist on location l1
>>                (cost=0.00..4.16 rows=150 width=65)
>>                (actual time=3.354..10.757 rows=3 loops=211880)
>>                Index Cond: ((l1.objectid = l2.objectid) AND 
>> (l2.intermine_start <= l1.intermine_start) AND (l2.intermine_end >= 
>> l1.intermine_start))

This indexscan is accounting for 10.757 * 211880 msec, which is 99%
of the runtime.

			regards, tom lane
В списке pgsql-performance по дате отправления
От: dforum
Дата:
Сообщение: Re: GiST index performance
От: Matthew Wakeling
Дата:
Сообщение: Re: GiST index performance
FAQ