Vous n'êtes pas identifié(e).
Oui, on peut augmenter cette limite. Plus vous l'augmenter, plus la durée d'analyse de la requête et de création du plan d'exécution sera longue. En gros, les petites requêtes prendront un peu plus de temps, les moyennes peuvent prendre beaucoup plus de temps, les longues peuvent gagner un peu. Il est difficile de répondre précisément à une question comme ça.
Guillaume.
Hors ligne
-> Flo :
Les COALESCE dans les jointures sont utilisés car on fait une jointure sur une table, mais avec une valeur provenant de deux tables jointes précédemment et ayant potentiellement la valeur à NULL.
Cela mériterait sans doute d'être remplacé par une jointure externe...
Hors ligne
-> Flo
Certainement, cependant je n'ai pas encore assez de recul sur le schéma pour attaquer.
PS : désolé nos messages se sont encore croisés.
-> Gleu
Très bien merci pour l'info. Y-a-t'il des préconisations en ce qui concerne le champ de l'acceptable nb jointures, nb champs retournés avec postgres ?
Me souvient avoir vu une sorte de documentation dans le style mais pour Oracle.
Hors ligne
Pas de limite à ma connaissance sur le nombre de jointures. Le nombre de champs dépend principalement de leur taille, ce qui fait varier le nombre de champs de 250 à 1600 en gros.
Guillaume.
Hors ligne
Que vous soyez avec des vues ou non ne change rien à l'optimisation, car le moteur "déplie" les vues en faisant une transformation au niveau table.
Cependant il est possible qu'en intégrant vos vues à votre requête vous vous rendiez compte qu'une simplification est possible. C'est donc une bonne pratique que de réintégrer le code SQL des vues dans les requêtes lorsque ces dernières sont complexes.
Vous pouvez augmenter la valeur du join_collapse_limit de façon assez important et de modifier le geqo_threshold en conséquence. Personnellement je met 64 et 16, car les bases de données que je travaille sont assez complexes. Mais vous devez avoir le matériel en conséquence (CPU, RAM...).
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
Que vous soyez avec des vues ou non ne change rien à l'optimisation, car le moteur "déplie" les vues en faisant une transformation au niveau table.
Cependant il est possible qu'en intégrant vos vues à votre requête vous vous rendiez compte qu'une simplification est possible. C'est donc une bonne pratique que de réintégrer le code SQL des vues dans les requêtes lorsque ces dernières sont complexes.A +
C'est exactement ce que je voulais dire 
. Il est assez fréquent qu'on se rende compte, en remplaçant les vues par leur requête, que des tables sont inutilement jointes plusieurs fois. C'est en cela que je disais qu'il faut faire attention quand on joint des vues et des tables.
D'autre part, l'utilisation de COALESCE comme condition de jointure me laisse penser qu'il y a un problème dans le modèle de données, ou dans la requête elle-même. Je n'ai jamais vu de cas où on avait besoin d'une telle chose, même dans des cas très tordus.
Dernière modification par flo (25/07/2011 10:22:23)
Hors ligne
Je comprends parfaitement vos commentaires.
En fait en creusant un peu et en récupérant d'autres infos, ils semblent que les utilisateurs de l'application souhaitent fréquemment des extractions pour faire ce qui s'apparente davantage à des statistiques (BO serait à son affaire je pense ou BIRT à voir).
Bref, ils souhaitent avoir un maximum d'informations sur le fonctionnel dans le même fichier quitte à rajouter des informations et encore des informations.
D'où le nombre de jointure croissant. Toutes ces requêtes génèrent des xls.
Je ne vois pas pour le moment de porte de sortie...
En ce qui concerne les coalesce dans les conditions, il s'agit de ramener des informations d'une table x en fonction de la valeur de la clé étrangère d'une table a ou b.
Sachant que la clé étrangère n'est pas systématique en b mais l'est en a.
Certaines des vues font des calculs ( group by, having, disctinct...),ce qui me parait pour le coup difficilement réintégrable dans une seule et même requête.
Hors ligne
En ce qui concerne les coalesce dans les conditions, il s'agit de ramener des informations d'une table x en fonction de la valeur de la clé étrangère d'une table a ou b.
Sachant que la clé étrangère n'est pas systématique en b mais l'est en a.
Je ne comprends toujours pas à quel besoin cela répond. Je ne comprends pas sans un exemple.
Certaines des vues font des calculs ( group by, having, disctinct...),ce qui me parait pour le coup difficilement réintégrable dans une seule et même requête.
Raison de plus pour décortiquer cela, et les réintégrer dans la requête (au moins pour l 'analyse)
Je ne vois pas pour le moment de porte de sortie...
J'en vois 2 :
Faire des extractions planifiées (vos utilisateurs ont-ils vraiment besoin de faire des extractions à la demande? peuvent-ils se contenter d'une extraction par jour? heure?). J'ai connu le cas d'un utilisateur m'ayant affirmé avoir besoin d'une vision instantanée pour des statistiques, alors que les batchs passaient 1 fois par nuit, et que les modifications en journée étaient rarissimes (en gros seulement en cas de corruption des données les administrateurs pouvaient modifier une ligne).
Optimiser la requête. Mais en effet, il vous faudra connaître bien le schéma, et ce que fait la requête.
Hors ligne
