oui.

zeoc/ = 12 Juillet, 2005 - 16:33

oui.

Bonjour dire que PostgreSQ

Christophe Chauvet/ = 12 Juillet, 2005 - 16:34

Bonjour

dire que PostgreSQL est mauvais est un peu fort, effectivement après l'insertion des données le VACUUM ANALYSE a t'il été fait ?
ensuite l'équivalence des types entre PostgreSQL et SQLServer a t'elle été judiscieuse pour PostgreSQL ?
pour comparer les performances de ces 2 SGBD il faut les tester dans leur environnement natif à savoir Windows pour SQLServer et FreeBSD (ou Linux) pour PostgreSQL.

Ensuite quel outils a servi à mesurer ces temps ? (pour chacun des 2).

Après éventuellement on pourra s'attaquer à l'optimisation de postgreSQL.

Christophe.

le vacuum a été fait comme

zeoc/ = 12 Juillet, 2005 - 16:51

le vacuum a été fait comme je l'ai précisé dans un mail précédent...
sur l'équivalence de types si je connaissais les choses judicieuses à faire je les ferais (c'est aussi pour ça que je viens dans ce forum)

Par ailleurs me dire de comparer PostgreSQL /Linux avec SQLS/Windows c'est bien gentil mais moi ma plateforme cible c'est pas Linux mais Windows, alors si PostgreSQL n'est bon que sous son environnement natif faut le dire ca m'évitera de perdre du temps...
Quant à savoir si les outils de mesure sont les bons je me poserai la question quand les écrats seront réduit et pas à un facteur 4!!!

Donc bon j'ai failli m'énervé mais non...;)

PS: au fait j'avais mis des guillemets à "mauvais"...

Ce que je voulais dire c'est

Christophe Chauvet/ = 12 Juillet, 2005 - 17:08

Ce que je voulais dire c'est que PG sera beaucoup plus performant sur une plateforme de type Unix, la version windows fonctionne mais pour ma part je m'en servirais seulement pour développer, pas pour un serveur de prod.

chose suivant, il serait bien de nous préciser l'outils utilisé pour cette mesure sous PG, et si la requête était lancé sous psql voir PGAdmin3 cela nous donnerais beaucoup plus de valeur, pourrait t'on également avoir le résultat de l'explain plan sur cette requête afin de vérifier la bonne utilisation des index.

Christophe.

P.S. Je ne fais que poser des questions, ne pas y voir un contenu offensent.

les temps PG sont pris sur

zeoc/ = 12 Juillet, 2005 - 18:11

les temps PG sont pris sur PGAdmin3 (ceux de SQLServer sur l'analyze de Entreprise Manager).

Tout d'abord la requete :

select champ from table_test group by champ

"champ" était à l'origine un varchar(4) puis j'ai recréé le jeu de test avec un char(4) ce qui n'a pas changé grand chose.
Que je créé ou pas des index (sauf si je m'y prends mal) ne change rien au temps NI à l'explain qui est toujours de la forme :

HashAggregate (cost=64409.09..64409.09 rows=63 width=8)
-> Seq Scan on table_test (cost=0.00..56324.27 rows=3233927 width=8)

voilà.

PS: désolé si j'avais mal interprété la 1ere réponse et merci de s'interesser à mon pb...;)

Info supplémentaire : en

zeoc/ = 13 Juillet, 2005 - 10:18

Info supplémentaire :

en re-créant la base en LATIN1 au lieu d'UNICODE j'ai gagné 30%...
Question subsidiaire :
PG est-il sensé utilisé les index sur un group by simple, si oui quelle sorte d'index ?
merci.

Group by et index

Jean-Paul Argudo/ = 16 Juillet, 2005 - 19:00

Bonjour,
Ci-après les résultats d'un test rapide que j'ai fait (sur mon portable, ça a un peu chauffé hihihi): Config: debian gnu/linux, pg 8.0.3:

test=# \d ma_table

              Table "public.ma_table"

     Column     |            Type             | Modifiers

----------------+-----------------------------+-----------

 mata_cod_prod  | numeric(3,0)                | not null

 mata_dat_eff   | timestamp without time zone | not null

 mata_no_adhes  | numeric(10,0)               | not null

 mata_cod_supp  | character(6)                | not null

 mata_nom       | character(20)               |

 mata_flg_actif | character(1)                |

 mata_parts     | numeric(18,5)               |

 mata_valuc     | numeric(18,5)               |

 mata_ea        | numeric(15,2)               |

Indexes:

    "ma_table_pkey" PRIMARY KEY, btree (mata_cod_prod, mata_no_adhes,

mata_cod_supp, mata_dat_eff) CLUSTER

    "idx_mata_flg_actif" btree (mata_flg_actif)

test=# select count(*) from ma_table;

  count

  ---------

   1592714

   (1 row)
test=# explain select mata_cod_prod from ma_table group by mata_cod_prod;

                                      QUERY PLAN

--------------------------------------------------------------------------------------

 Group  (cost=293299.90..301238.76 rows=12 width=10)

   ->  Sort  (cost=293299.90..297269.33 rows=1587772 width=10)

         Sort Key: mata_cod_prod

         ->  Seq Scan on ma_table  (cost=0.00..55240.72 rows=1587772 width=10)

(4 rows)
test=# create INDEX idx_mata_cod_prod on ma_table(mata_cod_prod);

CREATE INDEX

test=# VACUUM ANALYZE ma_table;

VACUUM

test=# explain select mata_cod_prod from ma_table group by mata_cod_prod;

                                               QUERY PLAN

--------------------------------------------------------------------------------------------------------

 Group  (cost=0.00..66112.64 rows=12 width=10)

   ->  Index Scan using idx_mata_cod_prod on ma_table (cost=0.00..62130.85 rows=1592714 width=10)

(2 rows)

On remarque que l'ajout de l'index a amélioré de manière très significative le coût de la requête... parceque l'optimiseur de PG utilise l'index, comme on pouvait s'y attendre.

Si vous n'avez pas le même comportement, même si votre PG est sous Windows, c'est que vous avez loupé une étape, ou alors qu'il y a un gros loup quelque part... Tenez-nous au courant.

Cordialement,

--
Jean-Paul ARGUDO
www.PostgreSQLFr.org

Quelques éléments de réponse

Jean-Paul Argudo/ = 16 Juillet, 2005 - 18:40

Bonjour,
Tout d'abord, je pense que le meilleur endroit pour que vous puissiez trouver des réponses précises sur le sujet des performances est la liste postgresql-performance. Vous pourrez vous y abonner et poster (gratuit bien sûr), en visitant ce site:

http://www.postgresql.org/community/lists/subscribe

...dans "Available Lists" sélectionnez 'performance'.

Ensuite, vous pourrez poster en anglais et avec précision votre problème. Je pense qu'il sera de nature à intéresser Tom Lane...

Sachez que lorsque vous créez un index, vous devez faire un vacuum analyze sur la table (vacuum analyze ma_table), sinon l'index n'est pas pris en compte.

Vous dites que lorsque vous ajoutez un index cela ne change rien aux temps de réponse ni à l'explain. Cela veut dire que l'optimiseur pense que sa méthode est toujours la meilleure; Soit il n'a pas la connaissance de(s) l'index, soit il y a des paramètres dans votre configuration qui influent de manière significative sur son "comportement"... C'est pourquoi j'aimerais que vous puissiez nous mettre à disposition, pour étude:

• une fiche descriptive de votre environnement de test (logiciels, matériel, etc)
• votre postgresql.conf
• un dump de votre base de test
• le source de la (des) requete(s) utilisée(s) pour les tests

J'espère que vous comprenez bien que sans cela, nous ne pourrons pas aller très loin pour vous aider :-/...

Cordialement,

--
Jean-Paul ARGUDO
www.PostgreSQLFr.org

Merci...J'étais en congés..

zeoc/ = 10 Août, 2005 - 10:44

Merci...J'étais en congés...
Je reprends tout ça dès que possible...

J"'ai enfin réussi à faire

zeoc/ = 11 Août, 2005 - 11:18

J"'ai enfin réussi à faire en sorte que PG utilise l'index.
enable_hashagg = false
dans la config.
MAIS les temps de réponse sont similaires.

Bonjour, Via ce forçage vou

Jean-Paul Argudo/ = 11 Août, 2005 - 13:44

Bonjour,
Via ce forçage vous vous exposez à de grosses difficultés... En effet, le paramétrage "enable_hashagg = false" vaut pour toutes les bases PostgreSQL installées. Ce genre de paramétrage n'existe que pour faire des tests, ne l'oubliez jamais !

Parce qu'interdire ainsi à l'optimiseur d'utiliser telle ou telle méthode est absolument dangereux. Vous pourrez probablement avec cette astuce améliorer les temps d'UNE requête, mais cela sera au détriment des autres ! Dans votre exemple, que les temps de réponse soient similaires ne m'étonne pas du tout, cela prouve que l'optimiseur avait bien choisi le meilleur chemin. Il ne faut pas croire qu'un index améliore systématiquement tout comme par magie...

Bien des fois PG, préférera un full table scan que de passer par un index, parceque c'est tout simplement moins le chemin optimal dans bien des cas... Dans votre exemple, je pense que votre index doit avoir une sélectivité peu intéressante, ou alors que votre table n'a pas un nombre de tuples significatif, ce qui peut expliquer que PG le boude. Mais avec l'activité de la base, et des vacuum analyze, il se peut qu'à un moment PG décide d'utiliser votre index, parceque tout simplement, ce sera alors le meilleur choix.

Conclusion: en tant que DBA, vous posez les index là où cela vous semble judicieux, et laissez ensuite PG décider tout seul s'il doit les utiliser ou pas: Faites-lui donc confiance, il fait toujours pour le mieux !

--
Jean-Paul ARGUDO
www.PostgreSQLFr.org

Je suis d'accord avec vos rem

zeoc/ = 11 Août, 2005 - 14:43

Je suis d'accord avec vos remarques...

Mais PG reste donc beaucoup plus mauvais que SQLServer (dans ce cas précis).
Ce n'est pas une critique juste une constatation et je suis convaincu que je peux trouver plein d'autres cas ou PG est bien meilleur que SQLServer ;-)

Je vais essayer un PG sous Linux pour voir...

Merci à tous.

Bonjour à tous, J'ai lu a

thom/ = 7 Octobre, 2005 - 11:58

Bonjour à tous,

J'ai lu attentivement tous vos posts, ce qui m'a incité à faire des tests sur ma base PostgreSQL 8.0.3 installée sur XP,

Sur cette base les éléments suivants :
CREATE TABLE mvstoc (
tmvt text,
nart text,
qtmv numeric(15,3),
ktmv numeric(15,3),
dtmv integer
);

CREATE INDEX idx_dtmv ON mvstoc USING btree (dtmv);
CREATE INDEX idx_nart ON mvstoc USING btree (nart);
CREATE INDEX idx_tmvt ON mvstoc USING btree (tmvt);

MVSTOC contient 1114091 lignes avec 2834 occurence de "nart"

Et voici l'"analyze" sur la requete:
"select nart from mvstoc group by nart order by nart"

---->

Sort (cost=26495.62..26498.11 rows=994 width=15) (actual time=4297.000..4297.000 rows=2834 loops=1)
Sort Key: nart
-> HashAggregate (cost=26446.14..26446.14 rows=994 width=15) (actual time=4281.000..4281.000 rows=2834 loops=1)
-> Seq Scan on mvstoc (cost=0.00..23660.91 rows=1114091 width=15) (actual time=0.000..2311.000 rows=1114091 loops=1)
Total runtime: 4297.000 ms

Même après un vacuum analyze MVSTOC

Pourquoi PG utilise-t-il le Seq Scan au lieu de l'index ?

Bonjour Thom Dans ta requ

Christophe Chauvet/ = 8 Octobre, 2005 - 14:44

Bonjour Thom

Dans ta requête select nart from mvstoc group by nart order by nart, Pg doit de toute de toute façon parcourir tous les enregistrements, donc je vois pas pourquoi il s'embèterait à utiliser un quelconque index, de plus le GROUP BY est inutile ici, je ne vois pas d'utilisation d'aggrégat.

quand je vois cette phrase:
MVSTOC contient 1114091 lignes avec 2834 occurence de "nart"

je verrais plutôt une requête de ce genre:
SELECT nart FROM mvstoc WHERE nart LIKE '%nart%'

et là l'index sur nart va être utilisé.

pour infos, Oracle aurait réagit de la même façon que PG a ce type de requête.

Cordialement.

Christophe Chauvet.