Vacuum FC4

cia/ = 23 Juin, 2006 - 16:39

Bonjour,

Les deux bases PG sont absolument identiques.

Sous pgsql, en SU, j'ai lancé
vacuumdb --analyze mybase
mais aucun message d'info, mais une exécution très rapide et un retour sous pgsql. Toutefois, je suis sorti de pgsql et j'ai relancé ma requête pour obtenir un résultat aussi catastrophique qu'avant le vacuum. J'ai sans doute mal appliqué la commande vacuumdb..

J'aimerai bien viré pg 8.0.3 mais j'avoue humblement ne pas savoir comment désinstaller et réinstaller une nouvelle version de pg :-((

J'ai viré la 8.0.3 pour inst

cia/ = 27 Juin, 2006 - 14:38

J'ai viré la 8.0.3 pour installer la version jdbc-8.1.3-3-1PGDG.i686.rpm mais sans plus de succès. Ca se traîne toujours autant..
J'ai comme la triste impression que ça n'intéresse personne, alors on remettra l'utilisation de 8.x.x à plus tard. Dommage :-((

Déja les 2 bases ne se trouv

Christophe Chauvet/ = 27 Juin, 2006 - 17:08

Déja les 2 bases ne se trouve pas sous les mêmes distribs, y'a une FC4 et une Mandrake, il se peut qu'au niveau du noyau certains paramètres soit différents.

ensuite un explain plan de la requête ne serait pas inutile pour voir ce qu'il est possible d'améliorer.

Ensuite syntaxiquement la requête est elle bien écrite ?

Cordialement.

Christophe Chauvet
http://kryskool.org/

Précision : Il s'agit de la

cia/ = 27 Juin, 2006 - 18:59

Précision : Il s'agit de la même base, installée sous Mandriva avec 7.4.13, et sous FC4 avec une 8.1.3, quant à la requête elle est assez compliquée et écrite soigneusement pour un résultat qui, jusqu'à présent, était parfait avec les versions antérieures de PG.

Actuellement, j'ai désinstallé la PG 8.1.3 pour la remplacer par la 7.4.13, et je tente péniblement de mettre en oeuvre le serveur PG sous FC4 en local, afin de vérifier si le problème est issu de FC ou de la version 8.1.3.

Merci de l'intérêt porté à mon problème

Bonjour

Jean-Paul Argudo/ = 28 Juin, 2006 - 10:24

Bonjour,

Nous ne doutons aucunement de vos capacités à écrire une requête correctement. Comprenez cependant que vous ne nous donnez rien pour vous aider (la requête, un bout de schéma, un EXPLAIN ANALYZE, un postgresql.conf ?) !

De plus, vous parlez d'un problème précis pour 1 requête ! Quid des autres ? Il y a de plus un fossé entre les performances entre un PG 8 et un PG 7, que ce soit un 8.0 ou un 8.1... Je trouve vraiment domage que vous soyez revenu en arrière aussi vite, sans nous donner de vrais moyens de vous aider.

Cordialement,

--
Jean-Paul ARGUDO
www.dalibo.com

Abstreint au résultat..

cia/ = 28 Juin, 2006 - 12:13

[.. vous ne nous donnez rien pour vous aider (la requête, un bout de schéma, un EXPLAIN ANALYZE, un postgresql.conf ?) ! ]

Tout à fait raison.. et je m'en excuse :-(
Comment faire, pour "quoter", pour joindre des images et/ou des fichiers à mon message ?

En ce qui concerne les autres requêtes, qui sont bien moins lourdes, notre client testeur ne nous a pas fait de remarques, et nos tests n'ont pas fait ressortir de dégradations significatives.

La décision de revenir en arrière avec une 7.4.13 a été prise principalement pour comparer le comportement de la fameuse requête avec la Fedora Core 4. Malheureusement, nous n'avons pas trop les moyens de faire du labo. Il s'agit d'une application "front office", et le confort de nos clients compte avant toutes considérations technique.
Mais dès la tranquillité chez notre client, nous réinstallerons la dernière version de PG et nous mettrons en batterie tous les outils de tests, car ici nous sommes persuadés de la superiorité de PG.

Résultats requête

cia/ = 28 Juin, 2006 - 23:51

L'exploitation de la grosse requête sous FC4 avec PG 7.4.13 ne pose aucun souci. Par conséquent j'en dédui que la FC4 n'est pas en cause.
Néanmoins nous avons remonté une version 8.1.3 sous une FC4 en relançant la requête au moyen de phppgadmin, et le résultat fut presque aussi mauvais qu'avec notre application (Java).
Demain nous espérons trouver un peu de temps pour lancer la requête avec EXPLAIN ANALYZE et vous fournir aussitôt les résultats.

A bientôt

EXPLAIN ANALYZE

cia/ = 29 Juin, 2006 - 17:48

Bonjour,

Comme convenu, voici le EXPLAIN ANALYZE de la requête qui se traîne sous PG 8 + FC4

SELECT DISTINCT m.id_produitgen, m.etat, m.foyer, m.matieredeverre, m.code, m.nom, m.codediametre, m.indicerefraction, m.prixvente, f.raisonsociale FROM ( SELECT m.*, c.catalogue FROM ( SELECT m.id, m.nom, m.foyer, m.indicerefraction, m.code, m.matieredeverre, p.etat, g.codediametre, g.prixvente, g.id_produitgen FROM modeledeverre m, promotions p, ( SELECT c.*, p.prixvente FROM ( SELECT c.modeledeverre, d.codediametre, c.id_produitgen FROM ( SELECT gr.modeledeverre, gr.diametreverre, gr.id_produitgen FROM grillefabricationverre gr INNER JOIN zonefabrication z ON z.id = gr.zonefabrication WHERE z.cylindremin<=0 AND z.cylindremax>=0 AND z.spherebasgauche<=0.0 AND z.spherehautgauche>=0.0 ) c INNER JOIN diametreverre d ON c.diametreverre=d.id ) c , plagetarif p, grillefabricationverre g, diametreverre d WHERE p.id_grille = g.id_produitgen AND g.diametreverre = d.id AND d.codediametre = c.codediametre AND c.modeledeverre = g.modeledeverre AND p.cylindredebut<=0.0 AND p.cylindrefin>=0.0 AND p.spheredebut<=0.0 AND p.spherefin>=0.0 ) g WHERE m.id=g.modeledeverre AND m.actif = true AND m.promotion=p.id AND m.foyer = 1000 AND m.matieredeverre=1000 ) m INNER JOIN modele_catalogue c ON m.id=c.id ) m INNER JOIN ( SELECT catalogue.id, ent.raisonsociale FROM catalogue INNER JOIN (SELECT e.id, e.raisonsociale FROM entreprises e WHERE e.raisonsociale = 'ESSILOR') ent ON ent.id = catalogue.fournisseur ) f ON m.catalogue=f.id

Unique (cost=3029.87..3029.90 rows=1 width=1629) (actual time=57598.519..57600.986 rows=192 loops=1)

-> Sort (cost=3029.87..3029.87 rows=1 width=1629) (actual time=57598.508..57599.177 rows=192 loops=1)

Sort Key: gr.id_produitgen, p.etat, m.foyer, m.matieredeverre, m.code, m.nom, d.codediametre, m.indicerefraction, p.prixvente, e.raisonsociale

-> Nested Loop (cost=190.90..3029.86 rows=1 width=1629) (actual time=39739.474..57593.245 rows=192 loops=1)

Join Filter: ("inner".id = "outer".fournisseur)

-> Hash Join (cost=190.90..3026.18 rows=1 width=1237) (actual time=289.064..57455.036 rows=1029 loops=1)

Hash Cond: ("outer".catalogue = "inner".id)

-> Nested Loop (cost=189.73..3024.93 rows=15 width=1237) (actual time=278.951..57430.417 rows=1029 loops=1)

-> Nested Loop (cost=189.73..2978.34 rows=1 width=1253) (actual time=267.808..57341.548 rows=469 loops=1)

-> Nested Loop (cost=189.73..2972.46 rows=1 width=1260) (actual time=257.125..57282.424 rows=469 loops=1)

Join Filter: ("inner".id_grille = "outer".id_produitgen)

-> Nested Loop (cost=189.73..308.27 rows=1 width=1260) (actual time=215.740..377.389 rows=636 loops=1)

Join Filter: (("inner".codediametre)::text = ("outer".codediametre)::text)

-> Hash Join (cost=189.73..296.31 rows=2 width=1268) (actual time=215.577..292.916 rows=1896 loops=1)

Hash Cond: ("outer".modeledeverre = "inner".modeledeverre)

-> Seq Scan on grillefabricationverre g (cost=0.00..84.57 rows=4357 width=24) (actual time=0.010..23.191 rows=4357 loops=1)

-> Hash (cost=189.73..189.73 rows=1 width=1244) (actual time=212.886..212.886 rows=0 loops=1)

-> Nested Loop (cost=53.40..189.73 rows=1 width=1244) (actual time=55.594..210.516 rows=469 loops=1)

-> Nested Loop (cost=53.40..183.76 rows=1 width=852) (actual time=39.392..133.257 rows=469 loops=1)

-> Hash Join (cost=53.40..159.80 rows=4 width=860) (actual time=25.013..73.515 rows=1060 loops=1)

Hash Cond: ("outer".modeledeverre = "inner".id)

-> Seq Scan on grillefabricationverre gr (cost=0.00..84.57 rows=4357 width=32) (actual time=9.862..30.558 rows=4357 loops=1)

-> Hash (cost=53.40..53.40 rows=1 width=828) (actual time=12.487..12.487 rows=0 loops=1)

-> Seq Scan on modeledeverre m (cost=0.00..53.40 rows=1 width=828) (actual time=5.041..11.130 rows=299 loops=1)

Filter: ((actif = true) AND (foyer = 1000) AND (matieredeverre = 1000))

-> Index Scan using zonefabrication_pkey on zonefabrication z (cost=0.00..5.98 rows=1 width=8) (actual time=0.042..0.044 rows=0 loops=1060)

Index Cond: (z.id = "outer".zonefabrication)

Filter: ((cylindremin <= 0::double precision) AND (cylindremax >= 0::double precision) AND (spherebasgauche <= 0::double precision) AND (spherehautgauche >= 0::double precision))

-> Index Scan using diametreverre_pkey on diametreverre d (cost=0.00..5.96 rows=1 width=408) (actual time=0.141..0.146 rows=1 loops=469)

Index Cond: ("outer".diametreverre = d.id)

-> Index Scan using diametreverre_pkey on diametreverre d (cost=0.00..5.96 rows=1 width=408) (actual time=0.016..0.023 rows=1 loops=1896)

Index Cond: ("outer".diametreverre = d.id)

-> Seq Scan on plagetarif p (cost=0.00..2650.94 rows=1060 width=16) (actual time=0.041..76.048 rows=3644 loops=636)

Filter: ((cylindredebut <= 0::double precision) AND (cylindrefin >= 0::double precision) AND (spheredebut <= 0::double precision) AND (spherefin >= 0::double precision))

-> Index Scan using promotions_pkey on promotions p (cost=0.00..5.87 rows=1 width=9) (actual time=0.090..0.095 rows=1 loops=469)

Index Cond: ("outer".promotion = p.id)

-> Index Scan using modele_catalogue_pkey on modele_catalogue c (cost=0.00..46.41 rows=15 width=16) (actual time=0.111..0.151 rows=2 loops=469)

Index Cond: (c.id = "outer".modeledeverre)

-> Hash (cost=1.13..1.13 rows=13 width=16) (actual time=9.990..9.990 rows=0 loops=1)

-> Seq Scan on catalogue (cost=0.00..1.13 rows=13 width=16) (actual time=9.864..9.922 rows=13 loops=1)

-> Seq Scan on entreprises e (cost=0.00..3.66 rows=1 width=408) (actual time=0.095..0.116 rows=1 loops=1029)

Filter: ((raisonsociale)::text = 'ESSILOR'::text)

Total runtime: 57602.485 ms

43 row(s)

Total runtime: 58,201.784 ms

SQL executed.

Désolé pour la lourdeur du message mais je n'ai pas trouvé comment joindre un fichier et/ou une image. A votre disposition pour des informations complémentaires.

Cordialement

No reply .. C'est compliqué ?

cia/ = 25 Juillet, 2006 - 18:03

Comme on m'y a invité, j'ai remonté une version 8.1.x et réalisé les tests que l'on m'a demandé, et comme vous pouvez le constater, je les ai mis à votre disposition depuis le 29-06-2006. Depuis, aucune réponse malheureusement. J'aimerai pourtant utilisé une version 8.1.x et serai prêt à vous rendre compte des améliorations et/ou des problèmes contatés.

Dois-je penser que le problème exposé ne représente aucun intérêt ?

Cordialement

Réponse :*)

Jean-Paul Argudo/ = 26 Juillet, 2006 - 01:11

Bonjour,

Pour répondre à votre dernière question, toutes les personnes qui répondent sur ce forum le font de manière bénévole ou sur leur temps de travail, gracieusement offert par leurs directions respectives, et nous ne sommes hélas pas beaucoup à répondre...

Peut-être pourriez-vous tenter un post sur la mailing-list française (voir http://archives.postgresql.org/pgsql-fr-generale/), où vous pourrez trouver une plus large audience que ce forum.

Pour ma part, je note plusieurs choses:

• la forme générale de la requete de type Select from (select from (select(...)))... me fait penser qu'elle est (mal) générée par un middleware ou autre application? Si oui, quel est-il?...
• utilisez-vous des types de données NUMERIC dans votre application en lieu et place de flottants (float..)? Si oui, sachez que ce type de données est contre-performant, il est "fait pour" gérer des nombres de type NUMERIC(98,23)... à utiliser à bon escient. La règle est d'utiliser des types de données les "plus proches du C", et de bannir NUMERIC(x,y) quand c'est possible. On trouve hélas trop d'applications migrées depuis Oracle (NUMBER(x,y)...): en méconnaissance de cause, trop de DBAs migrent cela en NUMERIC(x,y)...
• votre postgresql.conf dans ce cas nous serait vraiment utile, pour vérifier au moins qu'il y a un tunning, même très sommaire, du serveur PG. Vous pourrez donc attacher (désormais, j'ai activé cette option suite à votre 1er post...) un fichier: vous devez pour cela EDITER le post original de ce thread, vous verez tout en bas une option "ATTACHER UN FICHIER": je vous invite à nous faire part de votre postgresql.conf...
• je note que des alias de sous-requêtes sont utilisés plusieurs fois (deux "c", deux "m"), cela nuit à la lecture du code. J'ai bien tenté une réécriture du type select ... from .. where (en une seule fois, pas de sous-select!), mais je n'arrivais plus à savoir avec quel "m" ou "c" jouer :-(
• peut-être faudrait-il décomposer toutes ces requêtes imbriquées en autant de vues, et faire les jointures entre les vues, pour plus de clarté. Ok, nous sommes d'accord, cela ne changera probablement rien aux performances... Mais admettez que la maintenabilité du code sera plus simple. [Remarque non avenue si la requêtes est (mal) auto-générée...]

J'ai encore quelques idées, mais il est tard, et plus trop le temps de faire quelques tests...

Essayez de re-poster la même requête mais avec des nom d'alias uniques cette fois, et je tente une ré-écriture... maintenant je ne sais pas dans quelle mesure cela vous aidera...

Cordialement,

NB: désolé pour le lag pour ma réponse...

--
Jean-Paul ARGUDO
www.dalibo.com