Problème de temps de réaction

Bonjour,

J'entreprends de porter sous PostgreSQL les applications de gestion, que j'ai
réalisées depuis plusieurs années sous d'autres SGBDR.

Pour commencer, c'est l'application de comptabilité générale qui fait l'objet
du portage. C'est aussi parce que j'y ai les plus gros fichiers en terme de
nombre d'enregistrement.

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

Le fichier concerné est celui des écritures. Il est ainsi construit à l'image
exacte de celui dont il provient.

CREATE TABLE ecritu (
ecritu_societe DECIMAL(2,0) ,
ecritu_periode VARCHAR(4),
ecritu_date DATE ,
ecritu_ligne VARCHAR(8) ,
ecritu_piece VARCHAR(8) ,
ecritu_code_piece VARCHAR(2),
ecritu_ref_piece VARCHAR(12) ,
ecritu_compte VARCHAR(8) ,
ecritu_collectif VARCHAR(8),
ecritu_journal VARCHAR(8) ,
ecritu_central VARCHAR(1),
ecritu_libelle VARCHAR(30),
ecritu_montant DECIMAL(10,2),
ecritu_sens VARCHAR(1) ,
ecritu_lettre VARCHAR(2) ,
ecritu_echeance DATE,
ecritu_etat VARCHAR(2),
ecritu_operateur DECIMAL(2,0),
ecritu_paye DECIMAL(10,2),
ecritu_trop_percu DECIMAL(10,2),
ecritu_code_tiers VARCHAR(8),
ecritu_no_tiers DECIMAL(6,0),
ecritu_dev_compta VARCHAR(4),
ecritu_dev_piece VARCHAR(4),
ecritu_numerateur DECIMAL(8,4),
ecritu_denominateur DECIMAL(8,4),
ecritu_mnt_piece DECIMAL(10,2),
PRIMARY KEY
(ecritu_societe,ecritu_journal,ecritu_date,ecritu_piece,ecritu_ligne)
);
CREATE INDEX ecritu_index_2 ON ecritu
(ecritu_societe,ecritu_compte,ecritu_date,ecritu_piece,ecritu_ligne);
CREATE INDEX ecritu_index_3 ON ecritu
(ecritu_societe,ecritu_compte,ecritu_lettre,ecritu_sens,ecritu_ref_piece);

Le premier index a pour objet de lister date à date les écritures d'un journal
auxiliaire d'une société.

Le second a pour objet de lister date à date les écritures d'un compte d'une
société.

Et le troisième sert à produire les lettres de relance d'un groupe de comptes
d'une société.

La composition des ces indexes est telle qu'ils sont sans doublon.

La table "ecritu" a été chargée par la commande suivante :

COPY ecritu FROM '/home/ggix/ecritu.txt' USING DELIMITERS '|';

Le fichier "ecritu.txt" contient un peu plus de 785000 enregistrements et
provient d'un autre SGDBR (commercial, en l'occurence DataFlex de
Dataaccess). La durée du chargement a été de 17 minutes, ce qui est très
rapide.

En suite, pour "goûter", la requête :

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 USING > ;

Les premières lignes de résultat :
 ecritu_societe | ecritu_compte | ecritu_date | ecritu_piece | ecritu_ligne
----------------+---------------+-------------+--------------+--------------
              1 | 10100000      | 2001-05-01  | 00000000     | 00000001
              1 | 10100000      | 2002-05-01  | 00000000     | 00000001
              1 | 10610000      | 2000-10-31  | 00032864     | 00000003
              1 | 10610000      | 2001-05-01  | 00000000     | 00000002
              1 | 10610000      | 2002-05-01  | 00000000     | 00000002
              1 | 10682000      | 2000-10-31  | 00032864     | 00000002
              1 | 10682000      | 2001-05-01  | 00000000     | 00000003
              1 | 10682000      | 2002-04-30  | 00047636     | 00000002
              1 | 10682000      | 2002-05-01  | 00000000     | 00000003
              1 | 10688000      | 2000-10-31  | 00032864     | 00000004
              1 | 10688000      | 2001-04-30  | 00044994     | 00000001
              1 | 10688000      | 2001-05-01  | 00000000     | 00000004
              1 | 10688000      | 2002-04-30  | 00047636     | 00000003
              1 | 10688000      | 2002-05-01  | 00000000     | 00000004
              1 | 12000000      | 2000-10-31  | 00032864     | 00000001
              1 | 12000000      | 2001-04-30  | 00045004     | 00000131
              1 | 12000000      | 2001-05-01  | 00000000     | 00000005
              1 | 12000000      | 2002-04-30  | 00047636     | 00000001
              1 | 12000000      | 2002-04-30  | 00047688     | 00000130
              1 | 12000000      | 2002-05-01  | 00000000     | 00000005

(à l'écran, les caractères sont de pas constant)

Délai d'obtention de la première ligne : 2 mn 20 s
Délai de cloture de la lecture en touchant la lettre Q pour quitter (attente
bas de page affichée). : 10 secondes.

J'ai d'abord cru avoir mal formulé ma requête et, celle-ci vérifiée et non
amendée, je l'ai envoyée de nouveau et, là, le délai d'obtention a été,
certes, meilleur mais inacceptable : environ 55 secondes.

Toutes ces actions ont été faites sous l'interpréteur psql

Ces résultats me laisse perplexe...

La requête explicative EXPLAIN ANALYZE me donne le résultat suivant :

EXPLAIN ANALYZE 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 USING
> ;
                                                                  QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=16280.70..16290.92 rows=4091 width=49) (actual
time=51259.830..52246.911 rows=329640 loops=1)
   Sort Key: ecritu_societe, ecritu_compte, ecritu_date, ecritu_piece,
ecritu_ligne
   ->  Index Scan using ecritu_index_3 on ecritu  (cost=0.00..16035.27
rows=4091 width=49) (actual time=0.411..11878.919 rows=329640 loops=1)
         Index Cond: (ecritu_societe = 1::numeric)
 Total runtime: 53683.584 ms
(5 rows)

Je vois que le système a bien considéré que l'index à utiliser est le second
(sort key) c'est pourquoi je ne comprends pas pourquoi il semble faire son
balayage via le 3ème index, qui n'est pas concerné par cette requête.

Le délai de réponse de cette requête explicative a été de 1 mn 5 s.

Je m'en remets à votre sagacité et vous remercie par avance de toute
explication ou conseil !

--
PhD
enregistré Linux #353129