Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#1 16/02/2009 03:48:19
- ricobanga
- Membre
table cache pour optimisation, oui mais truncate est réservé à l'owner
Bonjour,
Je m'excuse si j'aurais mieux fait de mettre ce post dans la partie "optimisation", mais il m'a semblé qu'il s'agissait plutôt d'un problème général au sujet de truncate, ou globalement d'une réécriture de table.
je dois faire une requête qui nécessite des jointure avec une vue, et ceci fréquemment. (vérification de liens entre articles de contrats)
La vue est en elle même assez complexe et a beaucoup de lignes. L'opération était donc super longue ...
J'ai donc fait une table "cache", dans la quelle je copie le contenu de ma vue, et tout va très vite ...
Je n'ai à la "mettre à jour" que lorsqu'on insère de nouveaux liens (ce qui modifie en effet la vue), ce qui est beaucoup plus rare que la consultation.
Pour la mise à jour, j'ai une fonction qui doit faire un truncate puis un insert into [cache] (select * from [ma vue])
Oui mais je ne peux pas faire de truncate, si je ne suis pas l'owner de la table, ce qui n'est jamais le cas dans l'appli, et celle-ci contient 3 index de clés étrangères.
J'ai peur qu'en me contentant d'un delete from puis de l'insert, ma table va exploser l'espace disque, à moins qu'un autovacuum ...
Y-a-t-il une méthode pour éviter ce genre de problèmes avec truncate ou pour gérer des table qui doivent être souvent et intégralement réécrites ???
Merci beaucoup
Henry
Hors ligne
#2 16/02/2009 09:29:22
- gleu
- Administrateur
Re : table cache pour optimisation, oui mais truncate est réservé à l'owner
Il n'existera un droit sur TRUNCATE qu'à partir de la version 8.4 (voir http://developer.postgresql.org/pgdocs/ … rant.html).
Le mieux est actuellement est de se faire passer pour le propriétaire avec une fonction SECURITY DEFINER. Ce type de fonction s'exécute en tant que le propriétaire de la fonction. Il faut donc que le propriétaire de la fonction soit le propriétaire de la table, que la fonction soit défini en tant que SECURITY DEFINER et qu'elle ne fasse qu'un TRUNCATE la_table. Donc une fonction SQL suffit et sera suffisament rapide.
Guillaume.
Hors ligne
#3 16/02/2009 12:16:41
- ricobanga
- Membre
Re : table cache pour optimisation, oui mais truncate est réservé à l'owner
Fantastique, ça marche !
je vois bien tout l'intérêt de ce type de fonction pour ce genre d'opération
Merci de m'avoir répondu aussi vite ...
Henry
Hors ligne