PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  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  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48

Reqête très lente

Technique - optimisation | Reqête très lente

Par deleuse le 29/11/2007 - 17:45

Bonjour, je débute en postresql et j'ai un problème au niveau d'un requête sur une table.
En effet, lorsque je fais un :

select count(*) from matable;

=> le résultat s'affiche au bout de 15secondes. (Cette table contient 7500 lignes)

Si je fais la même requête sur des tables similaires , le résultat est instantané.

J'ai essayé de faire un 'vacuum verbose analyse matable;' sans résultat !

voici le résultat d'un \dt

                         Table "public.stat"
   Colonne   |   Type   |               Modifications
-------------+----------+--------------------------------------------
 stat_num    | integer  | not null default nextval('stat_seq'::text)
 stat_unum   | integer  |
 stat_dnum   | integer  |
 stat_dsnum  | integer  |
 stat_date   | date     |
 stat_dofw   | smallint |
 stat_ftnum  | integer  |
 stat_srvnum | integer  |
Index: stat_pkey primary key btree (stat_num),
       stat_i_dnum btree (stat_dnum),
       stat_i_dsnum btree (stat_dsnum),
       stat_i_unum btree (stat_unum)

Merci d'avance pour votre aide !

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

Pas de raison particulière...

Jean-Paul Argudo/ = 30 Novembre, 2007 - 21:56

Bonjour,

Votre problème est effectivement un peu curieux... Pouvez vous tenter les opérations suivantes:

  • REINDEX stat
  • \timing suivi du SELECT COUNT(*) FROM STAT;... Cela résout le problème?
  • si non, tentez un CLUSTER stat_pkey ON STAT;... suivi du select count(*).. Cela résout le problème?..
  • si non, quelle version de PG utilisez-vous et sous quel système d'exploitation? Cette table est-elle soumise à une forte charge en écriture? Si c'est le cas, vérifiez à deux fois comment votre application ouvre et ferme ses connexions, et surtout, ses transactions (n'y a t il pas des moments où un BEGIN est initié sans qu'il n'y ait jamais de COMMIT/ROLLBACK?...): cela pourrait être un problème de LOCK dans ce cas.

Cordialement,

--
Jean-Paul ARGUDO
http://dalibo.com | http://dalibo.org


Requête lente (Suite)

deleuse/ = 3 Décembre, 2007 - 17:34

Bonjour, merci pour ces informations.

1/ J'ai effectué un REINDEX sans résultat.

2/ J'ai effectué un DUMP de la base, puis dropdb et restauration du DUMP.
=> Le problème est résolu et les délais de réponses sont de l'ordre de la msec.

3/ Je n'ai pas effectué le CLUSTER...

4/ En ce qui concerne la version, il s'agit d'une 7.3.2 qui tourne sur Linux RedHat 9.0

5/ Il n'y a pas de transactions gérées à ce niveau.

Je vous remercie pour votre aide.

Cordialement,

James DELEUSE


7.3.2 !!!

SAS/ = 4 Décembre, 2007 - 09:58

Bonjour,

Le problème vient, il me semble, pour l'essentiel de la version de la base de données. Il s'agit d'une version 7.3, connue pour les risques qu'elle fait courrir aux données si les opérations de maintenance ne sont pas effectuées régulièrement.

Le fait d'obtenir une amélioration après un dump/restore laisse penser que vous n'étiez pas loin de corrompre vos données.

Librement,
Stéphane Schildknecht
dalibo
PostgreSQLFr


© PostgreSQLFr, tous droits réservés.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.