PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#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

Pied de page des forums