Discussion :

[marsup077]

Bonjour à tous,

Je débute dans l'administration des bases PostgreSQL, je vais sans doute poser des questions simplistes...

Un utilisateur se plaignant de mauvaises performances dans une fonctionnalité de son application, j'ai pu établir que cette fonctionnalité trop lente effectue un simple SELECT * sur une table (confirmé par l'éditeur de l'application), sans clause WHERE, sans ORDER BY, sans rien. Ce qui écarte les problématiques d'index et d'espace de tri.

Ce phénomène est reproductible à volonté, sur la base de production comme sur la base de test : ce simple "SELECT * from matable" met 26 secondes pour ramener 74000 lignes.

Pour améliorer les choses, j'ai tenté de jouer sur les paramètres suivants du fichier postgresql.conf...

shared_buffers
work_mem
maintenance_work_mem
effective_io_concurrency

... mais ça n'a eu aucun effet.

Y'a-t-il d'autres paramètres et/ou pistes qu ipermettraient d'améliorer les temps de réponse ?

Merci beaucoup.

[Waldar]

Il faut regarder plus la taille en nombre d'octets que de lignes, car une ligne contenant un booléen ou une ligne contenant 200 colonnes en char(2000) avec des LOBs, ce n'est pas le même problème.
Essayez de récupérer et fournir le script de création de cette table.

Pour vérifier si c'est le serveur qui est lent ou le débit réseau, mesurez le temps que met une duplication des données :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
create table t_test_perf
as
select * from matable;

[marsup077]

Le DDL de la table est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
CREATE TABLE matable
(
  folio character varying(6),
  nom character varying(50),
  dossier character varying(12),
  date_dos character varying(6),
  cb2 character varying(25),
  cb3 character varying(25),
  maq character varying(4),
  flag character varying(1),
  multi character varying(12),
  com1 character varying(100),
  com2 character varying(100),
  com3 character varying(100),
  com4 character varying(100),
  com5 character varying(100),
  com6 character varying(100),
  com7 character varying(100),
  com8 character varying(100),
  entete character varying(140),
  patient text,
  obr text,
  dynamique text,
  termine character varying(1),
  statut double precision,
  priorite character varying(30),
  sauvegarde double precision,
  folioparent character varying(12),
  datecreation timestamp without time zone,
  archive character varying(1),
  complement text
)
WITH (
  OIDS=FALSE
);

J'ai effectivement pensé à la taille moyenne des lignes : je l'ai estimée en divisant la taille de la table (donnée par pgAdmin), 115 Mo, par le nombre de lignes, 74533. Ce qui donne 1,6 Ko/ligne.

Et effectivement, le test de duplication de données est nettement plus rapide que le select * :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
create table matable2 as select * from matable;
La requête a été exécutée avec succés : 74533 lignes modifiées. La requête a été exécutée en 3438 ms.

[Waldar]

Ok, donc ce n'est pas un problème intrinsèque du serveur qui arrive à lire et à réécrire cette table en trois secondes.

Il faudrait vérifier le cheminement réseau entre votre utilisateur et la base de données.

[marsup077]

Je vais investiguer de ce côté-là.
Merci beaucoup.