Version imprimable
En ce qui concerne le problème dans la requête en la commentant par portion il semble que ce soit la dernière jointure qui entraîne l'explosion du système.
Et pour ce qui est de la compréhension, même avec le MPD j'avoue que je ne suis pas encore au bout. Mais j'avance.
HadanMarv
pardon, mais je n'ai toujours pas eu la réponse pour le paramètre :Citation:
Envoyé par sweetasnz
join_collapse_limit
qui est sans doute commenté dans le postgresql.conf.
As tu essayer d'augmenter en fonction du nombre de jointure de ta requête?
autant pour moi. sur tous les environnements le join_collapse_limit est commenté et prend donc la valeur par défaut à savoir 8.
et non je n'ai pas tenté de le modifier pour le moment car je ne connais pas encore sa fonction.
je viens de jouer avec le join_collaspe_limit
si je le passe à 16 / 32 / 64 à priori çà change rien.
en revanche si je mets 1 ma requête abouti en 30s...
c un miracle ou pas.
le plan d'exécution à aussi énormément changé.
Bref, pouvez-vous me dire :
1. Si le laisser à 1 est une bonne idée ou pas ?
2. pourquoi est-ce que avec la même requête et le param par défaut çà ne fait pas çà sur le serveur initial ?
3. Après une augmentation du shared_buffer faut-il faire un vacum ou autres ?
D'avance merci
HadanMarv
pour le 1 y a une bonne documentation :
http://www.postgresql.org/docs/8.4/s...fig-query.html (tout en bas)
http://www.postgresql.org/docs/8.4/s...cit-joins.html
=> ca peut entrainer des baisses de perf sur d'autre requête car la plupart des plans vont changer si vous faites la modif globallement.
Vous pouvez utiliser cette solution comme un fix temporaire mais j'essairai personnellement de tourner le coup au problème.
Pour le 2 :
j'ai pas compris la question
Pour le 3 :
Il faut reboot le serveur.
Merci pour les liens très instructifs.
la deuxième question reformulé :
Sur le serveur initial le join_collapse_limit n'a pas été modifié, hors la requête s'exécute correctement en une minute 30 mais au moins elle aboutit. Pourquoi ?
Rebooter le serveur carrément.
Bon je vais pas pouvoir le faire de suite. Dommage.
HadanMarv
tu n'as besoin que de redémarrer le service postgres.Citation:
Envoyé par HadanMarv
ah ok, je pensais que c'étais toute la machine.
cool, merci pour l'info.
Je viens de tenter un test.
J'ai positionné le shared_buffer à 1Go sur le serveur initial.
j'ai donc stoppé et relancé le service postgres.
J'ai arrêté et relancé le serveur Tomcat.
Je me suis rendu sur une des pages de l'application qui est connu pour sa lenteur
3 minutes environ... Et bien çà ne change rien...
Vous avez une idée ?
HadanMarv
avec join_collapse_limit = 1 aussi ?
Bonne question. Les plans d'exécutions sont différents et comme le reste semble identique par ailleurs, une théorie plausible serait une modification de l'optimiseur d'une version mineure à l'autre. En principe entre versions mineures, les changements pouvant présenter ce genre de risque sont bannis, mais il peut s'agir d'un effet de bord d'une correction de bug.Citation:
Envoyé par HadanMarv
Le fait de mettre join_collapse_limit à 1 doit empêcher l'optimiseur de réordonner les jointures, c.a.d qu'il les prend dans l'ordre où elles sont écrites dans la requête. A priori garder ce paramètre globalement va être contre-productif pour d'autres requêtes.
Outre le fait de simplifier la requête problématique, il y a plusieurs choses qui peuvent améliorer la situation en général:
1) augmenter la taille des échantillons statistiques (x10)
ALTER DATABASE nomdelabase SET default_statistics_target to 1000
suivi d'ANALYZE pour recalcul complet
2) si tu fais des vacuum full, ne plus les faire, laisser autovacuum se débrouiller
3) monter work_mem à 10Mb (c'est 1Mb par défaut je crois)
4) si le rapport disque/cpu est moins favorable pour le disque sur la nouvelle machine (=meilleur cpu mais pas meilleur disque) il peut être bon d'augmenter seq_page_cost et random_page_cost (valeurs par défault multipliables facilement par 2 ou 3)
L'effet de ces modifications est de changer les estimations de coût faites par l'optimiseur (le paramètre "cost" qui apparait dans EXPLAIN)