Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Le moteur full text de PostgreSQL est vraiment super et relativement facile à implémenter avec les différents tutos que vous avez réalisé.
J'indexe le contenu de document et globalement cela se passe bien.
En revanche je rencontre des problèmes avec certaines termes comme C++ ou C# ou autre termes contenant des caractères spéciaux qui ne sont pas inclus dans les texte vectorisés.
Y-a-t-il un moyen d'intégrer ces mots dans les recherches ?
Merci d'avance
Fabrice
Hors ligne
Avez-vous essayé de créer un dictionnaire des synonymes pour transformer C++ en cplusplus par exemple ? (jamais essayé, mais ce serait le premier test que je ferais)
Guillaume.
Hors ligne
Je n'ai pas essayé de dictionnaire de synonyme, il faut que je regarde comment ça marche
Hors ligne
Je viens d'essayer il semblerait que le parser agisse en premier en retirant les caractères spéciaux pour générer les tokens avant d'utiliser les dictionnaires
Hors ligne
Effectivement il faudrait mettre un analyseur lexical alternatif, sans quoi dans "C++" par exemple les + produisent le même lexème qu'un espace:
=# select ts_debug('C++');
ts_debug
--------------------------------------------------------------
(asciiword,"Word, all ASCII",C,{french_stem},french_stem,{})
(blank,"Space symbols",+,{},,)
(blank,"Space symbols",+,{},,)
Il est possible de faire une configuration texte avec son propre analyseur lexical, mais il faut l'écrire en C.
Un exemple ici: https://github.com/postgrespro/pg_tsparser
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Bonjour Merci pour vos reponses
Peut-on mixer plusieurs parser dans la meme BDD sur différents champs?
Il y a dans les contrib un test parser qui parse sur les espaces sans caractères alternatifs
exemple je veux indexer une liste de mots séparés par des espaces contenus dans un champ.
Peut-on sans problème utiliser par exemple une config fulltext pour un indexer champ et une autre différente pour indexer un autre champ?
Merci
Hors ligne
De mémoire le parser est relié à une configuration de recherche (TEXT SEARCH CONFIGURATION): on peut en avoir plusieurs par base et donner cette configuration comme argument "regconfig" aux fonctions comme to_tsvector ou to_tsquery.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci
C'est ce que j'avais vu mais je me demandais quels étaient les effets de bords possibles?
Hors ligne
Tant que vous ne mettez pas votre configuration spécifique en tant que conf par défaut (via default_text_search_config) postgres ne va pas l'utiliser implicitement, donc pas d'effet de bord à craindre.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
OK j'ai testé
2 config FTS
- French standard
- Custom avec le testparser
2 champs text avec du contenu vers 2 champs ts_vector via 2 triggerupdate (1 config FTS differente pour chaque trigger) + 1 index GIN pour chaque champ ts_vector
Lorsque je fait fait des ts_query sur ces L'un ou l'autre des champs les index sont utilisés et les recherches sont rapides
Si je fait une recherche combinant les 2 champs ts_vector les recherches sont beaucoup plus longue et les index ne sont pas utilisés
J'ai fait un test avec avec un seul index GIN comprenant ts_vector1 et ts_vector2 la c'est super rapide pour les recherches combinées
Je n'ai jamais utilisé d'index composé sur des champs ts_vector, que pensez-vous de cette solution?
Pour info, les données textes ne changent pas après enregistrement
Merci
Hors ligne
On peut voir l'EXPLAIN ANALYZE de la requête lente et la requête de création de l'index composé ?
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Pages : 1
