From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Stanislav Raskin <raskin(at)livn(dot)de> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: full text search to_tsquery performance with ispell dictionary |
Date: | 2011-05-11 14:42:05 |
Message-ID: | BANLkTikXvVz=h9z1FaQMJVQL4gGwvEDg=Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello
2011/5/11 Stanislav Raskin <raskin(at)livn(dot)de>:
>
> On 11.05.11 15:45, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
>>it is expected behave :( . A loading of ispell dictionary is very slow.
>>
>>Use a german snowball instead.
>>
>>You can you a some pooling connection software too.
>
>
> Thank you for the response.
> Is the dictionary german_stem supplied with postgresql a snowball stemmer?
> If yes, it sure is incredibly fast, but yields much worse results and thus
> fewer and worse matches for search queries.
>
> To use connections pooling is...difficult in my situation, to say the
> least. We currently use quite a complex pgcluster/corosync setup for
> multi-master replication, load balancing and high availability. To
> introduce connection pooling to this setup could turn out to be quite a
> big project.
>
German_stem is part of distribution. I am thinking so result of stems
are usable because the reports about slow speed are not often.
There are not exists Czech stem, so we have to use a ispell. I wrote a
patch that stores loaded dictionary in shared memory. You can find
source code in archive pg_hacker mailing list. But it isn't well
tested and it is just prototype - not accepted to pg. You can test it.
Sometimes people use a >>simple<< configuration here. It isn't best
but it is fast.
Regards
Pavel Stehule
> --
>
> Stanislav Raskin
>
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Stanislav Raskin | 2011-05-11 14:49:55 | Re: full text search to_tsquery performance with ispell dictionary |
Previous Message | Alex - | 2011-05-11 14:41:40 | Recursive select / updates |