Re: full text search to_tsquery performance with ispell dictionary

From: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
To: Stanislav Raskin <raskin(at)livn(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: full text search to_tsquery performance with ispell dictionary
Date: 2011-05-11 17:42:44
Message-ID: Pine.LNX.4.64.1105112142250.9772@sn.sai.msu.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 11 May 2011, Stanislav Raskin wrote:

>>
>>
>>
>> Yes, loading a large dictionary is known to be a fairly expensive
>> operation. There's been discussions about how to make it cheaper, but
>> nothing's been done yet.
>>
>> regards, tom lane
>
> Hi Tom,
>
> thanks for the quick response. Bad news for me ;(
> We develop ajax-driven web apps, which sort of rely on quick calls to data
> services. Each call to a service opens a new connection. This makes the
> search service, if using fts and ispell, about 100 times slower than a
> "dumb" ILIKE-implementation.
>
> Is there any way of hack or compromise to achieve good performance without
> losing fts ability?
> I am thinking, for example, of a way to permanently keep a loaded
> dictionary in memory instead of loading it for every connection. As I
> wrote in response to Pavel Stehule's post, connection pooling is not
> really an option.
> Our front-end is strictly PHP, so I was thinking about using a single
> persistent connection
> (http://de.php.net/manual/en/function.pg-pconnect.php) for all calls. Is
> there some sort of major disadvantage in this approach from the database
> point of view?
>
> Kind regards
>
> --
>
> Stanislav Raskin
>
>
>
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bborie Park 2011-05-11 18:01:33 Returning NULL to a set returning C type function
Previous Message Durumdara 2011-05-11 16:37:50 Read Committed transaction with long query