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

Astuces techniques et autres tours de mains!

Technique | Astuces techniques et autres tours de mains!

Par Jean-Paul Argudo le 22/04/2004 - 15:12

Sur le site TidBits vous trouverez tout un tas de petits articles et autres HOWTO (en anglais par contre, désolé!):

  • Performace
  • RĂ©plication
  • Astuces SQL
  • ...et bien d'autres encore!

Enjoy!

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.

Optimisation PostgreSQL 8 sous Windows

lucrol/ = 4 Avril, 2005 - 16:00

Bonjour,
Ayant configuré une base sur un serveur Windows 2003 server, je suis confronté à une lenteur anormale au niveau du traitement de certaines requètes.
J'ai regardé les "Tidbits" et j'ai modifié certains paramètres SANS amélioration notable.
Y a t-il un problème d'optimisation inhérent à la version Windows ?
Connaissez-vous des solutions d'amélioration ?

La table est constituée 143 champs avec la clef primaire + 15 index, elle contient 24679 enregistrements. Son ouverture est laborieuse.
La requète sur cette table inclus 6 jointures (LEFT OUTER JOIN) avec un tri sur 2 champs. Tous les champs inclus dans les jointures sont indexés (où des clefs primaires), les types de données sont identiques.
Ma personnalisation de la mémoire dans Postgresql.conf donne :
# - Memory -
shared_buffers = 32000 # min 16, at least max_connections*2, 8KB each
work_mem = 32768 # min 64, size in KB
maintenance_work_mem = 32768 # min 1024, size in KB
#max_stack_depth = 2048 # min 100, size in KB

Malgré celà la requète met 35 secondes à s'éxécuter

Tout avis me sera profitable...
D'abance merci


EXPLAIN ANALYZE

Jean-Paul Argudo/ = 9 Avril, 2005 - 09:31

Bonjour,

Pour ce qui est de l'optimisation d'une requĂŞte en particulier, nous avons absolument besoin de la sortie d'un EXPLAIN ANALYZE sur la requĂŞte. Sans cela, nous ne pouvons pas deviner ce qui ne va pas.

Cordialement,

--

Jean-Paul ARGUDO

www.PostgreSQLFr.org


RĂ©sultat de Explain Analyze

lucrol/ = 19 Avril, 2005 - 14:21

EXPLAIN ANALYZE
SELECT DISTINCT
vehicules.*,
compagnies.nomassur,
compagnies.contactassur,
employes.prenom_nom,
experts.nomexpert,
experts.cabinetexpert,
marques.nommarque,
soustraitants.nomst,
soustraitants.contactst
FROM soustraitants
RIGHT JOIN (marques
RIGHT JOIN (experts
RIGHT JOIN (employes
RIGHT JOIN (compagnies
RIGHT JOIN vehicules ON compagnies.codeassur::text = vehicules.codeassur::text) ON employes.codeemploye::text = vehicules.codechauffeur::text) ON experts.codeexpert::text = vehicules.codeexpert::text) ON marques.codemarque = vehicules.codemarque) ON soustraitants.codest::text = vehicules.codest::text
LEFT JOIN communes ON vehicules.cpgarage = communes.compteur
ORDER BY vehicules.nolp, vehicules.noimmat, vehicules.norecord ;

celĂ  donne :

"Unique (cost=35366.09..44744.11 rows=24679 width=2033) (actual time=15594.000..15782.000 rows=24679 loops=1)"
" -> Sort (cost=35366.09..35427.79 rows=24679 width=2033) (actual time=15594.000..15594.000 rows=24679 loops=1)"
" Sort Key: vehicules.nolp, vehicules.noimmat, vehicules.norecord, vehicules.dateaccord, vehicules.codemarque, vehicules.modele, vehicules.kms, vehicules.codeassur, vehicules.proprio, vehicules.codeexpert, vehicules.garage, vehicules.telgarage, vehic (..)"
" -> Hash Left Join (cost=46.98..3850.64 rows=24679 width=2033) (actual time=15.000..15406.000 rows=24679 loops=1)"
" Hash Cond: ("outer".cpgarage = "inner".compteur)"
" -> Hash Left Join (cost=15.29..3448.76 rows=24679 width=2033) (actual time=15.000..12797.000 rows=24679 loops=1)"
" Hash Cond: (("outer".codest)::text = ("inner".codest)::text)"
" -> Hash Left Join (cost=10.39..3132.90 rows=24679 width=1963) (actual time=15.000..10274.000 rows=24679 loops=1)"
" Hash Cond: ("outer".codemarque = "inner".codemarque)"
" -> Hash Left Join (cost=7.79..2848.95 rows=24679 width=1934) (actual time=0.000..7650.000 rows=24679 loops=1)"
" Hash Cond: (("outer".codeexpert)::text = ("inner".codeexpert)::text)"
" -> Hash Left Join (cost=4.70..2615.11 rows=24679 width=1856) (actual time=0.000..4992.000 rows=24679 loops=1)"
" Hash Cond: (("outer".codechauffeur)::text = ("inner".codeemploye)::text)"
" -> Hash Left Join (cost=3.27..2448.33 rows=24679 width=1813) (actual time=0.000..2565.000 rows=24679 loops=1)"
" Hash Cond: (("outer".codeassur)::text = ("inner".codeassur)::text)"
" -> Seq Scan on vehicules (cost=0.00..2195.79 rows=24679 width=1743) (actual time=0.000..30.000 rows=24679 loops=1)"
" -> Hash (cost=3.02..3.02 rows=102 width=84) (actual time=0.000..0.000 rows=0 loops=1)"
" -> Seq Scan on compagnies (cost=0.00..3.02 rows=102 width=84) (actual time=0.000..0.000 rows=102 loops=1)"
" -> Hash (cost=1.34..1.34 rows=34 width=52) (actual time=0.000..0.000 rows=0 loops=1)"
" -> Seq Scan on employes (cost=0.00..1.34 rows=34 width=52) (actual time=0.000..0.000 rows=34 loops=1)"
" -> Hash (cost=2.87..2.87 rows=87 width=92) (actual time=0.000..0.000 rows=0 loops=1)"
" -> Seq Scan on experts (cost=0.00..2.87 rows=87 width=92) (actual time=0.000..0.000 rows=87 loops=1)"
" -> Hash (cost=2.28..2.28 rows=128 width=33) (actual time=15.000..15.000 rows=0 loops=1)"
" -> Seq Scan on marques (cost=0.00..2.28 rows=128 width=33) (actual time=0.000..15.000 rows=128 loops=1)"
" -> Hash (cost=4.52..4.52 rows=152 width=84) (actual time=0.000..0.000 rows=0 loops=1)"
" -> Seq Scan on soustraitants (cost=0.00..4.52 rows=152 width=84) (actual time=0.000..0.000 rows=152 loops=1)"
" -> Hash (cost=27.95..27.95 rows=1495 width=4) (actual time=0.000..0.000 rows=0 loops=1)"
" -> Seq Scan on communes (cost=0.00..27.95 rows=1495 width=4) (actual time=0.000..0.000 rows=1495 loops=1)"
"Total runtime: 15828.000 ms"

Il est annoncé 15828 ms et pourtant lors de l'éxécution SANS EXPLAIN ANALYSE ça prend 32016+719 ms (si seulement 200 lignes extraites).

Il me semble que la lenteur soit dûe au nombre de champs de vehicules (143).

Existe-t-il une solution ?
D'avance merci...

Luc


Information sur l'analyze

Jean-Christophe Arnu/ = 28 Avril, 2005 - 10:06

Bonjour,

j'ai lu rapidement l'explain sans trop attacher d'importance au reste j'ai surtout remarqué qu'il ya beaucoup de seq scan. Ceci est dû au fait qu'il n'y a pas d'index ou que l'index n'est pas utilisé dans la requête. Je vous suggérerais de créer des index sur les champs importants des grosses tables (ou celles qui pourrait être amenées à grossir) afin d'obliger votre optimiseur à utiliser ces index. Une fois ces index créés n'oubliez pas de faire un vacuum analyze!

Jean-Christophe Arnu


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