Re: full text search to_tsquery performance with ispell dictionary - Mailing list pgsql-general

From Oleg Bartunov
Subject Re: full text search to_tsquery performance with ispell dictionary
Date
Msg-id Pine.LNX.4.64.1105112142250.9772@sn.sai.msu.ru
Whole thread Raw
In response to Re: full text search to_tsquery performance with ispell dictionary  (Stanislav Raskin <raskin@livn.de>)
List 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@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

pgsql-general by date:

Previous
From: Durumdara
Date:
Subject: Read Committed transaction with long query
Next
From: Bborie Park
Date:
Subject: Returning NULL to a set returning C type function