Re: Temps de réponse

From: Eric HAGENBACH <eric(dot)hagenbach(at)vif(dot)tm(dot)fr>
To: Sébastien Lardière <seb(at)ouvaton(dot)org>, Forum Postgres France <pgsql-fr-generale(at)postgresql(dot)org>
Subject: Re: Temps de réponse
Date: 2004-07-28 13:45:33
Message-ID: 4107ADFD.1080906@vif.tm.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Sébastien Lardière a écrit :

>Le Wed, 28 Jul 2004 14:24:47 +0200
>Eric HAGENBACH <eric(dot)hagenbach(at)vif(dot)tm(dot)fr> a écrit :
>
>
>
>>>>Where (T1.C1 = 'XX' and T1.C2 = '99' and T1.C3 = 'ZZZ' and (T1.C4 IN
>>>>('AA','BB'))
>>>>
>>>>
>
>
>
>>Ce sont des champs de type "chaine de caractères" (character varying(5)
>>pour le champs C2 par exemple)
>>
>>Par contre quand je regarde la description de la vue sous psql (\d
>>nomvue), le where est indiqué de la façon suivante:
>>where T1.C1::text = 'XX'::text (c'est valable pour tous les champs de la
>>condition). Est-ce que ça joue ?!?
>>
>>
>
>Oui, je pense que ca joue beaucoup, même. Un index sur un type 'text',
>c'est déjà lourd, alors en plus avec des milliers de ligne et dans une
>requete complexe !
>
>
>
En fait, la construction de la vue est fait par un script psql et
dedans il n'est pas précisé le type 'text' dans la condition (c'est le
script Oracle qui a été adapté pour fonctionner avec Postgres).
Toute la base de données à ainsi été conçue par migration d'une base
Oracle vers une base Postgres (notamment en utilisant l'outil ora2pg.pl)
ainsi tous les champs en varchar2 d'Oracle sont passés en character
varying chez Postgres.

>On ne le dira jamais assez, mais les choix de conceptions sont
>primordiaux pour la bonne tenue de la base de données. Ce n'est pas pour
>rien qu'il y a plusieurs types de données disponibles, encore faut-il
>s'en servir !
>
>Je serais toi, je commencerais par revoir completement les schémas de la
>base. De plus, tu utilises les Drivers ODBC, qui n'est pas ce qu'il y a
>de plus rapide, malheureusement ...
>
>
>
La base oracle est déjà installée chez des clients et la base Postgres
doit suivre la même structure. Nous avons un logiciel écrit en java qui
attaque les 2 bases, donc les modifs de structure doivent être minimes.

Quand à l'utilisation du driver ODBC, c'est pour l'instant la seule
solution qu'on a trouvé quand on passe par des outils du marché sous
windows (Cognos et MS olap) pour attaquer Postgres, et encore il y a
pas mal de paramétrage à mettre en ouvre par exemple pour le requêteur
de chez Cognos (merci le support Cognos pour son aide, par contre pour
Microsoft c'est plus flou !!).

Pour en revenir la structure, seule la jointure externe entre la table
principale et une table annexe avec des champs de types "chaine de car"
et "numérique" est peut-être inadéquate mais bon il s'agit d'une
jointure classique entre une entête de facture et le détail de la
facture. Les autres jointures se font par un seul champs de type
numérique (genre id). Il s'agit d'une représentation classique en étoile
(une table principale et des tables satellites).
Par contre, quand on utilise des outils tels que MS Olap, ceux-ci créée
d'autres jointures (pour relier un code client de la facture à une
dimension géographique par exemple): il peut y en avoir un certain
nombre . Et ces jointures viennent s'ajouter à la requête finale qui est
envoyée par l'outil vers la base Postgres.
Pour l'instant, nous n'avions pas eu trop de problème avec MS Olap et
Oracle : On avait simplement ajouter des vues sur la base pour faciliter
le travail du client
(au final c'est lui qui utilise MS Olap) et quelques index pour
accélérer les temps de réponses. Ces index ont également été ajoutés
pour Postgres.

En espérant avoir été plus clair sur le contexte d'utilisation de ces
requêtes.

Rq: Le but final de passer d'une base Oracle vers une base Postgres est
bien entendu de faire baisser les coûts (Et Postgres a été choisi par
rapport à Mysql à cause des vues qui ne sont pas gérées dans cette
dernière, pour le moment...).

Eric

In response to

Responses

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Jean-Max Reymond 2004-07-28 14:06:08 Re: Temps de réponse
Previous Message Sébastien Lardière 2004-07-28 12:55:46 Re: Temps de réponse