Re: GiST index performance

От: Tom Lane
Тема: Re: GiST index performance
Дата: ,
Msg-id: 26037.1239904355@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: GiST index performance  (dforum)
Список: pgsql-performance

Скрыть дерево обсуждения

GiST index performance  (Matthew Wakeling, )
 Re: GiST index performance  ("Kevin Grittner", )
  Re: GiST index performance  (Matthew Wakeling, )
  Re: GiST index performance  (Tom Lane, )
   Re: GiST index performance  (Matthew Wakeling, )
    Re: GiST index performance  (Tom Lane, )
     Re: GiST index performance  (Matthew Wakeling, )
   Re: GiST index performance  (Matthew Wakeling, )
    Re: GiST index performance  (Matthew Wakeling, )
     Re: GiST index performance  (Tom Lane, )
 Re: GiST index performance  (Matthew Wakeling, )
 Re: GiST index performance  (dforum, )
  Re: GiST index performance  (Tom Lane, )
  Re: GiST index performance  (Craig Ringer, )
 Re: GiST index performance  (Matthew Wakeling, )
  Re: GiST index performance  (Matthew Wakeling, )
   Re: GiST index performance  (Matthew Wakeling, )
    Re: GiST index performance  (Tom Lane, )
     Re: GiST index performance  (Oleg Bartunov, )
 Re: GiST index performance  (Matthew Wakeling, )
  Re: GiST index performance  (Bruce Momjian, )
   Re: GiST index performance  (Robert Haas, )
    Re: GiST index performance  (Bruce Momjian, )

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 по дате сообщения:

От: Kris Jurka
Дата:
Сообщение: Re: No hash join across partitioned tables?
От: Kris Jurka
Дата:
Сообщение: Re: No hash join across partitioned tables?