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

#1 17/02/2011 18:18:33

abdouB
Membre

VUE - ne pas calculer les champs non retournés

Bonjour,

J'aurai aimé avoir un peu d'aide sur le paramétrage des vues postgres.
J'ai une vue qui est composée de champs.
Parmis ces champs un champs est calculé et le temps de calcul de ce champ est excessivement long .
Appelons le champsAvecProbleme.

Si je fais un :
SELECT MAX( champSansProbleme ) FROM maVue;

bien que je fasse un max sur un autre champ que le champ à problème. Le temps d'exécution est extrêmement long.

Dans le cas ou j'ai besoin de ce champs, il est toujours accompagné d'une clause WHERE qui me réduit les temps de calculs....

D'où ma question :
Existe t il un moyen de ne pas calculer ce champs lorsque je n'y accède pas ???

Merci
Abdou

Hors ligne

#2 17/02/2011 23:45:42

daamien
damien clochard

Re : VUE - ne pas calculer les champs non retournés

Réponse courte : non .

La vue est recalculée entièrement (avec tous ses champs) à chaque fois que vous l'appelez quelque soit les champs que vous récupérez au final...

La solution consiste à contourner la vue : soit en créant une autre vue qui ne contient pas le champsAvecProbleme, soit en écrivant une requête qui accède directement au table...

Hors ligne

#3 17/02/2011 23:49:51

gleu
Administrateur

Re : VUE - ne pas calculer les champs non retournés

Que vous l'utilisiez ou pas, la vue le rajoute dans la vraie requête exécutée. Donc il est calculé.

La solution, utilisez une autre vue ou n'utilisez pas de vue.


Guillaume.

Hors ligne

#4 18/02/2011 10:53:42

abdouB
Membre

Re : VUE - ne pas calculer les champs non retournés

Bonjour,

Je me doutais bien que cela ne devait pas être possible.
En tout cas merci pour vos réponses.

Cordialement
Abdou

Hors ligne

#5 20/02/2011 16:37:44

SQLpro
Membre

Re : VUE - ne pas calculer les champs non retournés

C'est une des limitation de PostGreSQL. En effet sous Oracle, SQL Server ou DB2, les tables ou colonnes non utilisée dans la requête finale résultant d'une requête sur des vues sont systématiquement ignorées. Mais PostGreSQL commence à y venir. Dans la dernière version, l'optimiseur sait supprimer les jointures inutiles....

A +


Frédéric Brouard, alias SQLpro,  ARCHITECTE DE DONNÉES,  Expert langage SQL
Le site sur les SGBD relationnel et langage SQL   : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * *  Enseignant CNAM PACA, ISEN Toulon,  CESI Aix en Provence  * * * * *

Hors ligne

Pied de page des forums