From: | Bibi Mansione <golgote(at)gmail(dot)com> |
---|---|
To: | Hugh Ranalli <hugh(at)whtc(dot)ca> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Hunspell as filtering dictionary |
Date: | 2019-11-07 08:00:45 |
Message-ID: | CACZ67_XPG=FsLWBHxivF4CnrvhYsg5MeB3kAjK=biMBqPSCPPQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks. The problem is that the hunspell dictionary doesn't work with
unaccent so it is actually totally useless for languages with accents. If
one has to rely on stemming for words with accents, it is just a partial
solution and it is not the right solution.
Besides, the results returned by the hunspell implementation in postgresql
are incorrect. As you mentioned, it shouldn't return "con" and "tract" for
"contract". I also noticed many other weird results with other words in
French. They might have a bug in their code.
I ended up using ts_debug() with a simple stopword file in my own tokenizer
written with pllua that calls libhunspell directly using luajit and ffi. I
also wrote my own unaccent in Lua using the unaccent extension rules. It is
now two times faster to index French text and it gives much better results.
It produces a tsvector. Words returned by libhunspell stem() function get a
lower weight D and keep the same position as the original word.
My conclusion is that hunspell in postgres is useless for me at least
because it should be a filtering dictionary and it produces strange results
that pollute the original text.
I also think that the current implementation of TEXT SEARCH configuration
is not usable for serious purposes. It is too limited. Solr configuration,
while more complex, does a much better job.
Le mer. 6 nov. 2019 à 16:50, Hugh Ranalli <hugh(at)whtc(dot)ca> a écrit :
> On Tue, 5 Nov 2019 at 09:42, Bibi Mansione <golgote(at)gmail(dot)com> wrote:
>
>> Hi,
>> I am trying to create a ts_vector from a French text. Here are the
>> operations that seem logical to perform in that order:
>>
>> 1. remove stopwords
>> 2. use hunspell to find words roots
>> 3. unaccent
>>
>
> I can't speak to French, but we use a similar configuration in English,
> with unaccent first, then hunspell. We found that there were words that
> hunspell didn't recognise, but instead pulled apart (for example,
> "contract" became "con" and "tract"), so I wonder if something similar is
> happening with "découvrir." To solve this, we put a custom dictionary with
> these terms in front of hunspell. Unaccent definitely has to be called
> first. We also modified hunspell with a custom stopwords file, to eliminate
> select other terms, such as profanities:
>
> -- We use a custom stopwords file, to filter out other terms, such as
> profanities
> ALTER TEXT SEARCH DICTIONARY
> hunspell_en_ca (
> Stopwords = our_custom_stopwords
> );
>
> -- Adding english_stem allows us to recognize words which hunspell
> -- doesn't, particularly acronyms such as CGA
> ALTER TEXT SEARCH CONFIGURATION
> our_configuration
> ALTER MAPPING FOR
> asciiword, asciihword, hword_asciipart,
> word, hword, hword_part
> WITH
> unaccent, our_custom_dictionary, hunspell_en_ca, english_stem
> ;
>
> There was definitely a fair bit of trial and error to determine the
> correct order and configuration.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias Apitz | 2019-11-07 11:39:39 | type SERIAL in C host-struct |
Previous Message | Peter | 2019-11-06 22:14:20 | Re: Locked out of schema public (pg_dump lacks backup of the grant) |