Re: Problème de temps de réaction

Bonjour,

On Wednesday 04 May 2005 17:17, phdbx wrote:
> Bonjour et merci de vos réponses rapides. Cependant, quelques précisions me
> manquent encore. En effet, le lundi 2 Mai 2005 10:30, vous avez écrit :
>
> > Déjà il faut impérativement changer les types des champs ... et passer en
> > FLOAT et en INT un maximum de chose. Tu utilises des VARCHAR par choix ou
> > par obligation ? Le type TEXT peut-être bien plus efficace sur les index
> > ... à étudier ...
>
> 1. Je ne vois vraiment pas l'intérêt d'utiliser le type FLOAT pour les
> rubriques numériques, car je ne dois avoir pour ces rubriques que des
> valeurs en pleine précision et non des valeurs en "ordre de grandeur"
> (notation scientifique). C'est pour cela, qu'à la lecture de bouquins (John
> C. Worsley & Joshua D. Drake, PostgreSQL par la pratique, O'Reilly, 2002;
> S. Mariel, Services Web avec PostgreSQL et PHP/XML, Eyrolles 2002) et à
> l'écoute de quelques suggestions d'amis présumés connaisseurs, j'ai fini
> par préférer la déclaration au format 'DECIMAL (précision,échelle)'. Il y a
> bien le type MONEY mais il semble obsolète et, surtout, emporte d'autorité
> le symbole '$' dans l'expression des valeurs.

Comme tu veux ... mais sache de notre expérience avec PostgreSQL les
indexations seront beaucoup plus efficaces en FLOAT ...
Money est définitivement obsolète !

> 2. Pour ce qui des rubriques textuelles, il s'agit soit de codes
> mnémoniques (p. ex. le compte, la nature de la pièce comptable ou sa
> référence) soit du bref résumé de l'opération comptable qu'est le libellé
> d'une écriture. Ils ont chacun une longueur maximale (p. ex. 30 c. pour le
> libellé, 8 pour le compte, 2 pour la nature de la pièce, etc..) mais, à
> l'exception de 4 d'entre elles ('code_piece', 'sens', 'ligne' et 'piece'),
> elles n'ont pas de longueur minimale. C'est pourquoi le type 'TEXT' (coût
> en place pour les chaînes inférieures à 255 caractères) ne paraissait pas
> convenable alors que les types 'CHARACTER (n)' ou 'VARCHAR (n)'
> paraissaient bien appropriés. Enfin et pour couronner l'édifice, je ne
> comprends pas bien en quoi le type 'TEXT' pourrait améliorer les
> performances des indices où des rubriques de cette nature interviennent.

Idem c'est simplement des optimisations internes à PostgreSQL qui font que
souvent ces types de champs sont mieux indéxés ...
Il te suffit de faire le test ... si tu n'es pas convaincu et bien tu peux
toujours repasser dans ton état précédent ;o)

> > Deux questions émanent de ton analyse :
> > - Quelle configuration as-tu au niveau hardware ?
>
> P-III 900 Mhz
> dd IDE 160 Go
> mem 1 Go
> Mandrake Linux 10.1
>
> > - Quelle version de PostgreSQL ?
>
> 8.0.1
>
> > - Quels sont tes réglages au niveau de postgresql.conf ?
>
> En voici le contenu complet (pour alléger le message, j'ai supprimé les
> lignes marquées d'un '#', sauf celles indiquant les sections :
>
> shared_buffers = 1000 # min 16, at least max_connections*2, 8KB
>
> Autrement dit, toutes les valaurs par défaut, n'est-ce pas ?
>

Bon il faut impérativement optimiser ta configuration ... la configuration de
base est inexploitable dans beaucoup de cas ... sauf des bases de 200
enregistrements ...
A mon avis tu peux augmenter ton shared_buffers de façon significative.
Regarde aussi du côté du work_mem pour tes tris c'est important !
Idem pour les paramètres :
max_fsm_pages & max_fsm_relations & effective_cache_size

Vu ta machine tu peux passer les réglages de ces options de la façon
suivante :
random_page_cost = 2 # units are one sequential page fetch cost
cpu_tuple_cost = 0.01 # (same)
cpu_index_tuple_cost = 0.001 # (same)
cpu_operator_cost = 0.0025 # (same)

> > - As-tu fais un vacuum full verbose analyze après l'import des données ?
>
> Non. A qui cela sert-il ?

A quoi tu voulais dire ?? Parce que sinon ca ne sert qu'à toi ;o)
Bref VACUUM FULL VERBOSE ANALYZE de ta base permet de nettoyer la base, de
cleaner les index et également de faire une analyze des tables et dont de
permettre à l'optimiseur de faire correctement son travail ...

> > Merci de nous indiquer les dernières lignes de cette commande au passage
> > pour regarder tes paramètres du postgresql.conf
>
> Voici le résultat de la commande, que je viens de passer :
>
> #= VACUUM VERBOSE ecritu ;

Non je veux le résultat d'un VACUUM FULL VERBOSE ANALYZE;

> > Vu que tu ne passes qu'un paramètre à ta requête ... l'optimiseur estime
> > que l'index le plus court à parcourir et qui comporte la clé
> > ecritu_societe est l'index 3 ... ce qui me laisse penser si tu fais
> > souvent ce type de requête mono paramètre qu'il vaudrait mieux créer un
> > index sur ce seul paramètre plutôt que de faire des index à rallonge ...
> > mis à part pour les tris ...
>
> Ce qui me paraît étrange, c'est de ne pouvoir choisir moi-même l'index qui
> va bien.

Ceci n'est pas possible avec PostgreSQL à l'heure actuelle ... l'optimiseur
est censé trouver la meilleure solution ... et c'est souvent le cas aussi
étonnant que cela puisse paraitre !

> Ce serait assez intéressant de connaître le fonctionnement interne des
> différentes fonctions voire de connaître les primitives du système
> PostgreSQL car je trouve fort lourd de ne disposer que d'une instruction,
> SELECT, et ses polysémie pour accéder aux données. En outre, des fonctions
> assez simples telles que SUIVANT ou PRECEDENT ne semblent pas exister dans
> les polysémies de SELECT, ce qui signifie qu'on ne peut guère se promener
> au sein d'une table.

Si si ... tu peux utiliser les offset et les limit ... mais aussi te servire
de curseurs ...

Cordialement,
--
Hervé Piedvache

NOUVELLE ADRESSE - NEW ADDRESS :
Elma Ingénierie Informatique
3 rue d'Uzès
F-75002 - Paris - France
Pho. 33-144949901
Fax. 33-144882747