Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-fr-generale by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group