Re: Problème de temps de réaction

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 :
[...]
> > Le problème que je rencontre et auquel je ne comprends rien est l'extrême
> > lenteur d'obtention des résultats après requête
[...]
>
> 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.

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.

[...]
>
> 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 :

# -----------------------------
# PostgreSQL configuration file
# -----------------------------

[...]

#---------------------------------------------------------------------------
# FILE LOCATIONS
#---------------------------------------------------------------------------

[...]

#---------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#---------------------------------------------------------------------------

[...]
max_connections = 100
[...]

# - Security & Authentication -

[...]

#---------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#---------------------------------------------------------------------------

# - Memory -

shared_buffers = 1000 # min 16, at least max_connections*2, 8KB each
[...]

# - Free Space Map -
[...]

# - Kernel Resource Usage -
[...]

# - Cost-Based Vacuum Delay -

[...]

# - Background writer -

[...]

#---------------------------------------------------------------------------
# WRITE AHEAD LOG
#---------------------------------------------------------------------------

# - Settings -

open_datasync
[...]

# - Checkpoints -

[...]

# - Archiving -

[...]

#---------------------------------------------------------------------------
# QUERY TUNING
#---------------------------------------------------------------------------

# - Planner Method Configuration -

[...]

# - Planner Cost Constants -

[...]

# - Genetic Query Optimizer -

[...]

# - Other Planner Options -

[...]

#---------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#---------------------------------------------------------------------------

# - Where to Log -

[...]

# - When to Log -

[...]

# - What to Log -

[...]

#---------------------------------------------------------------------------
# RUNTIME STATISTICS
#---------------------------------------------------------------------------

# - Statistics Monitoring -

[...]

# - Query/Index Statistics Collector -

[...]

#---------------------------------------------------------------------------
# CLIENT CONNECTION DEFAULTS
#---------------------------------------------------------------------------

# - Statement Behavior -

[...]

# - Locale and Formatting -

[...]

# These settings are initialized by initdb -- they might be changed
lc_messages = 'fr_FR' # locale for system error message strings
lc_monetary = 'fr_FR' # locale for monetary formatting
lc_numeric = 'fr_FR' # locale for number formatting
lc_time = 'fr_FR' # locale for time formatting

# - Other Defaults -

[..]

#---------------------------------------------------------------------------
# LOCK MANAGEMENT
#---------------------------------------------------------------------------

[...]

#---------------------------------------------------------------------------
# VERSION/PLATFORM COMPATIBILITY
#---------------------------------------------------------------------------

# - Previous Postgres Versions -

[...]

# - Other Platforms & Clients -

[...]

--------------------- fin de postgresql.conf ------------------

> - Quelle est la valeur de statistic par défaut de ton postgresql.conf ?

#---------------------------------------------------------------------------
# RUNTIME STATISTICS
#---------------------------------------------------------------------------

# - Statistics Monitoring -

#log_parser_stats = false
#log_planner_stats = false
#log_executor_stats = false
#log_statement_stats = false

# - Query/Index Statistics Collector -

#stats_start_collector = true
#stats_command_string = false
#stats_block_level = false
#stats_row_level = false
#stats_reset_on_server_start = true

Autrement dit, toutes les valaurs par défaut, n'est-ce pas ?

> - Quel volume de données est censé te retourner cette requête ? 4000 lignes
au pif, entre le tiers et la moitié du nombre total de lignes, disons 340000.

> ou plus ? (cf l'analyze pas fait plus bas)
si c'est le nombre 329640, c'est tout à fait réaliste.

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

> 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 ;
INFO: vacuuming "public.ecritu"
INFO: index "ecritu_pkey" now contains 0 row versions in 2 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "ecritu_index_1" now contains 0 row versions in 2 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "ecritu_index_2" now contains 0 row versions in 2 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "ecritu_index_3" now contains 0 row versions in 2 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "ecritu": found 0 removable, 0 nonremovable row versions in 0 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM

> Le coup des 55 secondes semble normal ta table est en mémoire et donc le
> résultat est beaucoup plus facile à obtenir ... maintenant 55 secondes pour
> 800 000 enregistrements je comprends que tu sois pas content ! ;o)

Je me suis dit que, s'il faut attendre 55 secondes pour obtenir la première
ligne d'un tri sur index selon un seul critère, le système risque d'être
d'une intolérable lenteur si l'on veut tirer, par exemple, le journal des
ventes de la sté 1 pour la période du 1er au 28 février 2003, qui doit
représenter environ 8000 lignes.

>
> 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.

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.

Sous le SGDBR, que j'utilise encore mais que je souhaite quitter (toutes ses
évolutions se font actuellement et de manière exclusives vers Windows), je
n'ai aucun délai d'attente humainement sensible pour d'indentiques requêtes
sur le fichier 'ecritu' contenant exactement les mêmes lignes, d'une part,
et, d'autre part, ses fonctions primitives me permettent de naviguer dans le
fichier en utilisant les divers index + le n° d'ordre des enregistrements.
Cela peut être très confortable pour la maintenance du fichier.

Cordialement,
--
Philippe Dalléas
enregistré linux #353129