| 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: | Whole Thread | Raw Message | 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
| 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 |