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

Optimiseur : réécriture/simplification des requêtes avant exécution ?

Technique - optimisation | Optimiseur : réécriture/simplification des requêtes avant exécution ?

Par scheu le 31/01/2008 - 14:58

Bonjour

J'utilise Postgresql depuis peu. J'ai constaté sur ma base récemment installée un problème : l'optimiseur ne sait apparemment pas, quand c'est possible, simplifier une requête et la réécrire avant de l'exécuter. Exemple simple et reproductible :

ma_bdd=# create table test (n numeric);
CREATE
ma_bdd=# insert into test values (1); --> lancé 10 fois
INSERT
ma_bdd=# insert into test values (0); --> lancé 10 fois
INSERT
ma_bdd=# select count(*) from test;
count
-------
20
(1 row)
ma_bdd=# vacuum full analyze test;
VACUUM
ma_bdd=# explain select * from test where n = 1;
QUERY PLAN
------------------------------------------------------
Seq Scan on test (cost=0.00..1.25 rows=10 width=9)
Filter: (n = 1::numeric)
(2 rows)

ma_bdd=# explain select * from test where n = 1 and n = 1;
QUERY PLAN
-----------------------------------------------------
Seq Scan on test (cost=0.00..1.30 rows=5 width=9)
Filter: ((n = 1::numeric) AND (n = 1::numeric))
(2 rows)

En mettant "where n=1", l'optimiseur m'estime bien à 10 le nombre de lignes renvoyées, alors qu'en mettant "where n=1 and n=1", il m'estime à 5 (au lieu de 10 !), il a donc sous-estimé le nb de lignes renvoyées
L'optimiseur sait-il simplifier et réécrire une requête avant de l'exécuter ? Des paramétrages influent-ils au niveau du fichier postgresql.conf ou ailleurs ?
Ce problème m'embête grandement car à grande échelle des requêtes générées via BO peuvent contenir plusieurs fois la même condition (where n=1 and n=1 par exemple), et le fait que l'optimiseur sous-estime le nombre de lignes renvoyées me donne de mauvais plans d'exécutions lors de jointures complexes (utilisation de nested loop au lieu de hash join par exemple)

Quelqu'un aurait-il des explications sur ce comportement, et éventuellement une solution ?

Merci d'avance

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.

Bonjour,

escapek/ = 12 Février, 2008 - 19:04

Bonjour,
Quelle version de postgres utilises-tu ?
Pour info, voici ce que donne le même test avec la version 8.3:

ma_bdd=# create table test (n numeric);
CREATE
ma_bdd=# insert into test values (1); --> lancé 10 fois
INSERT
ma_bdd=# insert into test values (0); --> lancé 10 fois
INSERT
ma_bdd=# select count(*) from test;
ma_bdd=> vacuum full analyze test;
VACUUM
ma_bdd=> explain select * from test where n = 1;
QUERY PLAN
-----------------------------------------------------
Seq Scan on test (cost=0.00..1.25 rows=10 width=6)
Filter: (n = 1::numeric)
(2 rows)
ma_bdd=> explain select * from test where n = 1 and n = 1;
QUERY PLAN
-----------------------------------------------------
Seq Scan on test (cost=0.00..1.25 rows=10 width=6)
Filter: (n = 1::numeric)
(2 rows)

Les deux requêtes ont bien le même plan d'exécution, le même cout et la meme estimation du nombre de ligne retournées. Le filtre a été d'ailleurs simplifié automatiquement.
Si c'est possible, tu peux donc essayer sur une version de postgres plus récente.


J'utilise la version 8.2 Je

scheu/ = 13 Février, 2008 - 11:18

J'utilise la version 8.2
Je m'en vais tester la 8.3 alors

Un grand merci pour ta réponse


Effectivement je confirme apr

scheu/ = 14 Mars, 2008 - 17:50

Effectivement je confirme après test que c'est corrigé dans la version 8.3


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