Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Le ts_parser est par défaut compilé avec :
#define IGNORE_LONGLEXEME 1
(défini dans src/backend/tsearch/ts_parse.c )
ce qui fait que lors de l'appel à to_tsvector() les lexèmes d'une longueur supérieure à MAXSTRLEN sont ignorés.
Ce qui est très bien.
Cependant, dans src/include/tsearch/ts_type.h on a :
#define MAXSTRLEN ( (1<<11) - 1)
soit 2047.
Dans la mesure où en français le mot le plus long est de 26 lettres - et que je ne suis pas certain que dans les autres langues il soit pertinent non plus d'indexer des mots d'une telle longueur - je suis bien tenté de recompiler avec comme modification :
#define MAXSTRLEN ( (1<<6) - 1)
soit 63 lettres.
(ceci afin de me débarrasser de l'indexation de chaînes interminables purement parasites).
Pensez-vous que cela puisse avoir des effets de bord quelque part ?
Hors ligne
Attention, il s'agit d'octets et non de caractères. Selon l'encodage et les caractères utilisés, vous pouvez avez bien plus d'un octet par caractère. Cette constante est également utilisée comme taille maximale de token utilisable dans un tsvector ou un tsquery.
Sinon, je ne sais pas trop ce que donnerait l'utilisation d'un binaire ainsi modifié sur une base de données avec des index déjà créés sur du contenu qui serait alors ignoré.
Julien.
https://rjuju.github.io/
Hors ligne
Attention, il s'agit d'octets et non de caractères. Selon l'encodage et les caractères utilisés, vous pouvez avez bien plus d'un octet par caractère. Cette constante est également utilisée comme taille maximale de token utilisable dans un tsvector ou un tsquery.
Sinon, je ne sais pas trop ce que donnerait l'utilisation d'un binaire ainsi modifié sur une base de données avec des index déjà créés sur du contenu qui serait alors ignoré.
Ah oui bonne remarque pour la taille en octets.
Autrement, on est bien d'accord, il faut refaire les ts_vector et les index sur la base après ça.
Bon je vais essayer, sur mon P9 de bench.
Hors ligne
Une approche plus orthodoxe serait de faire un dictionnaire personnalisé qui éliminerait les léxèmes dépassant la longueur en question, qui peut d'ailleurs être un paramètre du dictionnaire.
L'inconvénient c'est qu'il faut le faire en C. Mais si vous en êtes à recompiler postgres, ce n'est pas forcément un problème.
Le code à produire est très simple en s'inspirant de src/backend/tsearch/dict_simple.c.
Les exemples dans contrib dict_int, dict_xsyn permettent aussi de voir comment packager ça dans une extension avec les déclarations de dictionnaire qui vont bien.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Pages : 1
