Vous n'êtes pas identifié(e).
Pages : 1
Bojour,
J'ai une petite question concernant l'utilisation d'un trigger.
J'utilise le trigger suivant :
CREATE TRIGGER tsupdate BEFORE INSERT AND UPDATE
ON doc FOR EACH ROW EXECUTE PROCEDURE
tsvectore_update_trigger(vec_description, 'pg_catalog.english', description)
vec_description étant une colonne contenant tsvector(description)
Lorsque j'ajoute des données dans ma table, vec_description est bien mis à jour et ça prend donc plus de temps. Par contre, lorsque j'en supprime, l'opération est très rapide, j'en conclus que vec_description n'est pas mis à jour.
J'ai bien essayé de rajouter dans mon trigger "BEFORE INSERT OR UPDATE OR DELETE" mais ça ne fonctionne pas...
Quelqu'un peut-il m'aider??
Merci
Hors ligne
La procédure stockée tsvectore_update_trigger sert à calculer la colonne tsvector, soit suite à une insertion, soit suite à une mise à jour. Après une suppression, il n'y a pas de nouvelle valeur de cette colonne, donc le trigger n'a pas d'intérêt dans ce cadre.
Bref, le trigger sur DELETE dans ce cas n'est pas utile.
J'en profite pour faire de la pub pour mon prochain article dans Gnu Linux Magazine France (donc numéro 110). Il sera sur la recherche plein texte. Pas sûr par contre qu'il te soit bien utile vu que tu as déjà l'air de connaître ce qui se fait en matière de recherche plein texte.
Guillaume.
Hors ligne
Ok merci.
J'utilise également un index GIN sur vec_description. Celui-ci sera-t-il mis à jour lors d'un delete?? Ma crainte est que si ce n'est pas le cas, après avoir supprimé des enregistrements, si l'index n'est pas à jour, il se peut que, lors d'une recherche, il croie toujours que ces enregistrements existent...
Hors ligne
Le fait que le trigger ne se déclenche pas sur les DELETE ne change en rien la gestion des index. D'ailleurs, PostgreSQL se débrouille très bien quand il n'y a aucun trigger sur une table... donc pas de raison de s'inquiéter.
De plus, au moins pour les index BTree, il n'y a pas d'information sur la disponibilité ou non de la ligne pointée par l'index dans l'index même. C'est pour cela qu'un parcours d'index demande une lecture plus ou moins complète de l'index puis une lecture ciblée de la table : les informations de visibilité des lignes ne sont stockées que dans la table. C'est pour cela aussi qu'un parcours d'index n'est pas toujours la solution. Si l'élément recherché se trouve dans plus de 50% de la table, ce sera contreperformant.
Guillaume.
Hors ligne
D'accord! Je te remercie...
Hors ligne
Pages : 1
