Re: Problème de temps

Bonjour,

Philippe Dalléas wrote:

>Bonjour,
>
>Voici par rapport à mon message d'hier quelques changements :
>
>1. j'ai modifié la table 'ecritu' en y ajoutant la rubrique 'ecritu_recnum' de
>type 'serial'. Elle constitue la PRIMARY KEY.
>
>2. J'ai renommé les index précédents, successivement, en 'ecritu_k1',
>'ecritu_k2' et 'ecritu_k3' afin qu'ils gardent les mêmes noms que sous
>l'ancien SGBDR
>
>3. J'ai rechargé les données en utioisant, bien sûr, la même commande et le
>fichier de données ASCII renouvelé afin d'y prendre le n° d'enregistrement et
>le mettre dans la colonne 'ecritu_recnum'
>
>4. Cette opération s'est faite très rapidement pour la taille chargée. Au
>cours du chargement, la série suivante de messages s'est affichée à l'écran.
>La fois précédente aussi, mais je n'y avais pas prêté une suffisante attention
>et ne les avais pas relevés, comme je viens de le faire :
>
>gg-compta=# \i /home/ggix/rdecritu
>LOG: checkpoints are occurring too frequently (26 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (26 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (27 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (28 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (26 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (28 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (27 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (28 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (26 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (28 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (29 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (29 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (29 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (29 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>LOG: checkpoints are occurring too frequently (29 seconds apart)
>HINT: Consider increasing the configuration parameter "checkpoint_segments".
>COPY
>gg-compta=#
>
>Qu'est-ce que cela veut dire ?
>
>
Je pense que comme il s'agit d'un chargement massif, les segments WAL se
remplissent très rapidement.
Comme ce n'est pas l'utilisation courante, ce n'est qu'un avertissement.

>
>Le chargement fait, j'ai lancé à nouveau la requête explicative de listage par
>compte pour la société 1 en supprimant l'argument d'opérateur 'USING >' :
>
>SELECT ecritu_societe,ecritu_compte,ecritu_date,ecritu_piece,ecritu_ligne FROM
>ecritu WHERE ecritu_societe=1 ORDER BY ecritu_societe, ecritu_compte,
>ecritu_date, ecritu_piece, ecritu_ligne ;
>
>Nette amélioration : le délai d'obtention de la première ligne est passé à
>environ 20 secondes au lieu des 2 mn 20 s. Cela est d'autant estimable que le
>nombre de comptes impliqués dans ces écritures est d'environ 5000.
>
>
Postgres a-t-il pris le bon index ? ecritu_k2 ?
Pour continuer sur le mail précédent, plutot que de faire Vacuum full
après le chargement massif,
il convient de faire :
*base=# Vacuum analyse ;*
pour que l'optimiseur ait les bonnes statistiques, pour prendre les
bonnes décisions.
et relancer le select.

Autre question : si on répète le meme ordre select, tout de suite après
, ce temps de 20s diminue -t-il ?

>Toutefois, 20 secondes devant un écran, c'est subjectivement long et
>j'aimerais assez que es premières lignes sortent quasi aussitôt :
>l'expérience m'a montré la force de cette rapidité de réaction sur les
>opérateurs au point que cela peut changer radicalement leur façon d'utiliser
>le logiciel voire leur attitude envers lui.
>
>
Je ne pense pas qu'un client ( opérateur) ait besoin d'avoir 5000 lignes
devant les yeux.
AMHA c'est l'appli (php, libpq ....) qui doit lui faire défiler les lignes.

>Pour ce qui est du paramètre 'USING', j'avais cru comprendre qu'il ne pouvait
>venir qu'après l'énumération des rubriques dépendantes du paramètre 'ORDER
>BY'.
>
>
Pour les tris, Postgres utilise ASC (par defaut) ou DESC.
Par compatibilité avec d'autre SGBD, il comprend USING < et USING >
comme ASC et DESC
cette clause porte sur la colonne immédiatement précédente. ( les lignes
de facture étaient triées en décroissant)

>J'ai fait alors un autre essai de la requête en posant le paramètre 'USING ="
>comme suit :
>
>SELECT ecritu_societe,ecritu_compte,ecritu_date,ecritu_piece,ecritu_ligne FROM
>ecritu WHERE ecritu_societe=1 ORDER BY ecritu_societe USING =, ecritu_compte,
>ecritu_date, ecritu_piece, ecritu_ligne ;
>
>Le délai de réponse a été un peu plus long (25 secondes) et m'a listé le
>résultat d'une manière que j'ai d'abord cru décroissante pour les comptes
>(??) mais en fait, en tournant plusieurs pages, j'ai compris que le listage
>se trouvait classé dans un assez savant 'bordel' !
>
>
Using = n'existe pas sous postgres ? c'était quoi le but ?

>Donc, pour l'instant, Frédéric a raison, je laisse tomber la clause 'USING'.
>
>
Merci,
A noter que Postgres met à la disposition des développeurs des scroll
cursor <http://www.postgresql.org/docs/8.0/interactive/sql-declare.html>
pour naviguer precedent, suivant dans le résultat d'un select

Bonne journée
Frédéric TURPIN
LFI <http://www.lfi.fr/>

>Merci encore de vos remarques éclairées.
>Cordialement,
>
>
>