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

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
3 commentaires | anciens sondages
Accueil » forums » Technique - optimisation

Performance avec index

Technique - optimisation | Performance avec index

Par Bertrand Cedric le 17/10/2005 - 17:29

bonjours je suis en train d'optimiser notre application qui tourne en J2EE, Tous les acces DB sont gérer par des CMP qui eux même génère l'SQL

le problème est, quand il charge une relation avec plus de 2 or les performance s'effondre

ce petit code devrais être plus parlant je pense

jboss=> select id_organiser from t_organiser where
jboss-> upperorganiser='1';
id_organiser
--------------
(0 rows)

Time: 0,000 ms
jboss=> select id_organiser from t_organiser where
jboss-> upperorganiser='1' or
jboss-> upperorganiser='2';
id_organiser
--------------
(0 rows)

Time: 10,000 ms
jboss=> select id_organiser from t_organiser where
jboss-> upperorganiser='1' or
jboss-> upperorganiser='2' or
jboss-> upperorganiser='3';
id_organiser
--------------
(0 rows)

Time: 1602,000 ms

il y a bien sure un index (btree) sur le champ upperorganiser

merci d'avance pour votre aide

PS: je rappelle je n'ai pas la main sur le sql donc impossible de passer par un in ou de lancer les requettes une par une
PS2 : le code plus haut est une simultaiotn de ce qui est générer par le serveur d'application
PS3: la DB est un psotgreql v8.01 sans aucune moddificaiton dans les fichier de config.

[ sujet précédent | sujet suivant ]

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.

Tout d'abord il faut utiliser

sparky/ = 18 Octobre, 2005 - 11:49

Tout d'abord il faut utiliser explain pour voir si l'index est ou non utilisé. Ensuite l'index n'est utilisé qu'après qu'on ait fait au moins un analyze sur la table.

En conclusion, pourrais-tu faire

analyze t_organiser;
explain select ...;

PS Pour optimiser ton application, tu devrais aussi optimiser la config ;)


[ Vous devez vous connecter pour poster des commentaires ]

merci pour la reponse je n

Bertrand Cedric/ = 18 Octobre, 2005 - 13:40

merci pour la reponse

je ne suis pas sure de comprendre tous ce qui est retourné mais je pense que la troisième requette n'utilise pas l'index

jboss=> explain select id_organiser from t_organiser where
jboss-> upperorganiser='1';
QUERY PLAN
---------------------------------------------------------------------------------
Index Scan using plop5 on t_organiser (cost=0.00..12157.12 rows=3146 width=49)
Index Cond: ((upperorganiser)::text = '1'::text)
(2 rows)

Time: 20,000 ms
jboss=>
jboss=> explain select id_organiser from t_organiser where
jboss-> upperorganiser='1' or
jboss-> upperorganiser='2';
QUERY PLAN
----------------------------------------------------------------------------------------------
Index Scan using plop5, plop5 on t_organiser (cost=0.00..24329.98 rows=6276 width=49)
Index Cond: (((upperorganiser)::text = '1'::text) OR ((upperorganiser)::text = '2'::text))
(2 rows)

Time: 10,000 ms
jboss=>
jboss=> explain select id_organiser from t_organiser where
jboss-> upperorganiser='1' or
jboss-> upperorganiser='2' or
jboss-> upperorganiser='3';
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------
Seq Scan on t_organiser (cost=0.00..32992.79 rows=9390 width=49)
Filter: (((upperorganiser)::text = '1'::text) OR ((upperorganiser)::text = '2'::text) OR ((upperorganiser)::text = '3'::text))
(2 rows)

Time: 10,000 ms

vous proposez quoi pour optimiser la config?


[ Vous devez vous connecter pour poster des commentaires ]

petit changement après sur

Bertrand Cedric/ = 18 Octobre, 2005 - 14:15

petit changement
après survole du document http://www.revsys.com/writings/postgresql-performance.html

j'ai mis a off la variable enable_seqscan
et j'obtiens

jboss=> select id_organiser from t_organiser where
jboss-> upperorganiser='1' or
jboss-> upperorganiser='2' or
jboss-> upperorganiser='3';
id_organiser
--------------
(0 rows)

Time: 0,000 ms
jboss=>
jboss=> explain select id_organiser from t_organiser where
jboss-> upperorganiser='1' or
jboss-> upperorganiser='2' or
jboss-> upperorganiser='3';
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------
Index Scan using plop5, plop5, plop5 on t_organiser (cost=0.00..53852.06 rows=13886 width=49)
Index Cond: (((upperorganiser)::text = '1'::text) OR ((upperorganiser)::text = '2'::text) OR ((upperorganiser)::text = '3'::text))
(2 rows)

Time: 0,000 ms

pensez vous que c'est une faute d'activer par defaut cette variable a off


[ Vous devez vous connecter pour poster des commentaires ]

pensez vous que c'est une f

Jean-Paul Argudo/ = 19 Octobre, 2005 - 15:22 

pensez vous que c'est une faute d'activer par defaut cette variable (enable_seqscan) à off ?

Oui, c'est une grossière erreur... Ça ne sert qu'à faire des tests, tenez-vous le pour dit. Toutes les autres requêtes vont pâtir de ce paramétrage.

À votre place, je contacterai directement les "responsables" de l'écriture de ces requêtes contre-performantes, pour leur expliquer que "OR" est à bannir dans les requêtes SQL (quel que soit le SGBD d'ailleurs), et qu'il peut être très avantageusement remplacé par "IN" comme vous le savez... De plus, il semble que l'utilisation des simples quotes force PG à faire des casts, alors qu'il semble ne s'agir que d'entiers, c'est bien domage.

N'espérez donc pas faire des miracles côté optimisation, hélas, elles seront toutes très limitées dans votre cas précis, et toujours dépendantes de l'écriture de la requête, qui doit être la plus intelligente possible, comme vous vous en doutez.

--
Jean-Paul ARGUDO
www.PostgreSQLFr.org


[ Vous devez vous connecter pour poster des commentaires ]

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