Skip site navigation (1) Skip section navigation (2)

Re: Problème de temps

From: Frédéric Turpin <linux(at)lfi(dot)fr>
To: pdalleas(at)free(dot)fr
Cc: Hervé Piedvache <herve(at)elma(dot)fr>,pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Problème de temps
Date: 2005-05-09 07:41:01
Message-ID: 427F140D.30107@lfi.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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,
>
>  
>

In response to

pgsql-fr-generale by date

Next:From: Masse JacquesDate: 2005-05-09 08:19:28
Subject: Re: Postgresql 8.0.2 et stockage des images
Previous:From: Sébastien DinotDate: 2005-05-09 07:36:05
Subject: CityVox se relance en misant sur PHP-PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group