Re: Understanding tsearch2 performance

Поиск
Список
Период
Сортировка
Искать
От
Kevin Grittner
Тема
Re: Understanding tsearch2 performance
Дата
Msg-id
4C3D7D5E0200002500033548@gw.wicourts.gov
Список
Дерево обсуждения
Understanding tsearch2 performance Ivan Voras <ivoras@freebsd.org>
Re: Understanding tsearch2 performance Oleg Bartunov <oleg@sai.msu.su>
Re: Understanding tsearch2 performance Ivan Voras <ivoras@freebsd.org>
Re: Understanding tsearch2 performance Oleg Bartunov <oleg@sai.msu.su>
Re: Understanding tsearch2 performance Ivan Voras <ivoras@freebsd.org>
Re: Understanding tsearch2 performance Stephen Frost <sfrost@snowman.net>
Re: Understanding tsearch2 performance Ivan Voras <ivoras@freebsd.org>
Ivan Voras <  ivoras@freebsd.org  > 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 по дате отправления
От: Kevin Grittner
Дата:
От: Ivan Voras
Дата:
FAQ