Re: Understanding tsearch2 performance

От: Kevin Grittner
Тема: Re: Understanding tsearch2 performance
Дата: ,
Msg-id: 4C3D7D5E0200002500033548@gw.wicourts.gov
(см: обсуждение, исходный текст)
Ответ на: Understanding tsearch2 performance  (Ivan Voras)
Ответы: Re: Understanding tsearch2 performance  (Ivan Voras)
Список: pgsql-performance

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

Understanding tsearch2 performance  (Ivan Voras, )
 Re: Understanding tsearch2 performance  (Oleg Bartunov, )
  Re: Understanding tsearch2 performance  (Ivan Voras, )
   Re: Understanding tsearch2 performance  (Oleg Bartunov, )
    Re: Understanding tsearch2 performance  (Ivan Voras, )
     Re: Understanding tsearch2 performance  (Stephen Frost, )
      Re: Understanding tsearch2 performance  (Ivan Voras, )
 Re: Understanding tsearch2 performance  ("Kevin Grittner", )
  Re: Understanding tsearch2 performance  (Ivan Voras, )
   Re: Understanding tsearch2 performance  (Oleg Bartunov, )
   Re: Understanding tsearch2 performance  ("Kevin Grittner", )
    Re: Understanding tsearch2 performance  (Ivan Voras, )

Ivan Voras <    > wrote:
> On 07/14/10 15:49, Stephen Frost wrote:

>> Regarding the statistics, it's entirely possible that the index
>> is *not* the fastest way to pull this data (it's nearly 10% of
>> the table..)
>
> I think that what I'm asking here is: is it reasonable for
> tsearch2 to extract 8,500 rows from an index of 90,000 rows in 118
> ms, given that the approximately same task can be done with an
> unindexed "LIKE" operator in nearly the same time?

The answer is "yes."  When it's 10% of the table, a sequential scan
can be more efficient than an index, as Stephen indicated.

-Kevin


В списке pgsql-performance по дате сообщения:

От: Hannu Krosing
Дата:
Сообщение: Re: Need help in performance tuning.
От: Ivan Voras
Дата:
Сообщение: Re: Understanding tsearch2 performance