Re: Postgresql partitionnement

Bonjour Pierre,

Si tes tables sont déjà créées coté Postgres, il est possible de copier les
données d'ORACLE directement dans la base postgres en spécifiant les
paramètres PG_DSN de ton fichier de configuration.

Olivier

Le 17 janvier 2014 09:34, pierre crumeyrolle <pierre(dot)crumeyrolle(at)c-s(dot)fr> a
écrit :

> ok merci pour toutes ces précisions
>
> questions supplémentaires
>
> quand j'utilise ora2pg pour migrer les données , ora2pg me génère des
> ordres insert , ça marche même pour des blobs oracle vers des bytea posgresl
> par contre si j'ai 100 millions de lignes , il va me générer 100 millions
> de lignes dans un fichier csv, y a t'il pas une technique plus efficace pour
> passer des données de ORACLE à posgresql lors d'une migration ( db link ou
> autre format ) ?
>
>
> merci
>
> Le 16/01/2014 14:32, Olivier Bernhard a écrit :
>
> Pierre,
>
> En relisant cet article que vous avez posté, quelques éléments
> supplémentaires :
>
> 1) L’article fait référence à postgresql 8.
>
> Les performances en insertion dans postgresql 9.3 ont été considérablement
> améliorées
>
> 2) L’auteur fait référence à l’utilisation de « rules » . Il existe
> également une autre solution utilisant des triggers.
>
> La doc de postgresql même en version 8.3 stipule que pour les
> performances, l’utilisation de triggers est généralement meilleure que les
> rules.
>
>
>
> *Olivier Bernhard*
> Database Administrator
>
>
>
>
>
> *From:* pgsql-fr-generale-owner(at)postgresql(dot)org [
> mailto:pgsql-fr-generale-owner(at)postgresql(dot)org<pgsql-fr-generale-owner(at)postgresql(dot)org>]
> *On Behalf Of *pierre crumeyrolle
> *Sent:* mercredi 15 janvier 2014 17:08
> *To:* pgsql-fr-generale(at)postgresql(dot)org
> *Subject:* Re: [pgsql-fr-generale] Postgresql partitionnement
>
>
>
> je viens de tomber sur cette article qui a trait au partitionnement :
> comparaison partitionnement postgresql et Sqlserver
>
> cet article montre comment on mets en place le partitionnement postgresql
> , j'ai l'impression que ça correspond à ce que décrit François
>
> par contre les conclusions sont pas très engageantes , qu'est ce que vous
> en penser ?
>
> ci joint le lien =>
> http://blog.developpez.com/sqlpro/p10378/langage-sql-norme/partitionner_une_table_comparaison_postg
>
>
> Le 15/01/2014 16:59, François Bouhet a écrit :
>
> Bonjour Pierre,
>
>
> Pour utiliser correctement le partitionnement, il y a quelques pièges à
> éviter, notamment dans l'interrogation des tables.
> Pour que l'analyseur de requêtes utilise le partitionnement, le where de
> la requête devra contenir un critère de la contrainte d'exclusion.
>
> En ce qui concerne les performances, cela change du tout au tout.. autant
> que de mettre (ou pas) des index sur les champs qui apparaissent dans le
> where !
> :-)
>
> Voici un exemple extrait d'une de mes bases de données : stockage de
> données boursières en Europe
> La table mère s'appelle cours_action_europe. On crée des tables filles
> pour chaque place de cotation identifiée par un code sur 5 chiffres (tous
> les codes finissent par 5 chiffres qui définissent la place de cotation)
> CREATE TABLE cours_action_10018() INHERITS (cours_action_europe) ;
> ALTER TABLE cours_action_10018 ADD CONSTRAINT
> place_cotation_definie_v2_10018 CHECK (code_eurofidai %100000=10018) ;
>
> CREATE TABLE cours_action_10025() INHERITS (cours_action_europe) ;
> ALTER TABLE cours_action_10025 ADD CONSTRAINT
> place_cotation_definie_v2_10025 CHECK (code_eurofidai %100000=10025) ;
>
>
> Comme il peut y avoir 50 millions de lignes sur une place, on partitionne
> à nouveau et on crée des tables petites-filles pour chaque année, la
> contrainte est sur la date, soit :
> CREATE TABLE cours_action_10018_1986() INHERITS (cours_action_10018) ;
> ALTER TABLE cours_action_10018_1986 ADD CONSTRAINT
> date_cotation_1986_intervalle_check CHECK ( (date_cotation >=
> '1986-01-01') AND (date_cotation <= '1986-12-31') ) ;
> CREATE TABLE cours_action_10018_1987() INHERITS (cours_action_10018) ;
> ALTER TABLE cours_action_10018_1987 ADD CONSTRAINT
> date_cotation_1987_intervalle_check CHECK ( (date_cotation >=
> '1987-01-01') AND (date_cotation <= '1987-12-31') ) ;
> ...
> CREATE TABLE cours_action_10018_2012() INHERITS (cours_action_10018) ;
> ALTER TABLE cours_action_10018_2012 ADD CONSTRAINT
> date_cotation_2012_intervalle_check CHECK ( (date_cotation >=
> '2012-01-01') AND (date_cotation <= '2012-12-31') ) ;
>
> Les deux requêtes suivantes n'ont pas du tout le même temps d'exécution :
> SELECT * FROM cours_action_europe WHERE code_eurofidai=110001409310018 ;
> SELECT * FROM cours_action_europe WHERE (code_eurofidai=110001409310018)
> AND (code_eurofidai%100000=10018) ;
>
> En effet, la première ne permet pas à l'analyseur de requêtes de déduire
> dans quelle table il peut directement aller, la seconde utilise la
> contrainte qui exclut les tables filles entre elles.
>
> Pour être clair, la seconde requête revient pratiquement à écrire ceci :
> SELECT * FROM cours_action_10018 WHERE (code_eurofidai=110001409310018) ;
> Les tables soeurs cours_action_xxxxx de la table cours_action_10018 ne
> sont pas parcourues.
>
> Pour les insertions, il faut en général écrire des déclencheurs, Les
> insertions sont évidemment beaucoup moins rapides. Si l'on peut insérer
> directement dans la bonne table (feuille terminale de l'arbre de
> l'héritage) et éviter le déclencheur, c'est mieux.
>
>
>
> Cordialement
> François Bouhet
>
> On 15/01/2014 15:53, pierre crumeyrolle wrote:
>
> Est simple à mettre en place ?
> en terme de performances quel temps de réponse constaté ?
>
>
>
>
> Le 15/01/2014 14:34, Cédric Villemain a écrit :
>
> Bonjour Pierre,
>
>
> quelqu'un a t il déjà mis en place du partitionnement sur une base
> postgresql ( table de plus de 100 millions de lignes )
>
> oui, peut-être pourriez-vous préciser votre question ?
>
>
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>
>
>
>
> --
>
> Administrateur Systèmes et Base de données
>
> téléphone: +33 (0)4 76 63 53 89 ; fax: +33 (0)4 76 63 53 86
>
> Adresse postale:
>
> CNRS / EUROFIDAI UPS 3390
>
> 150, rue de la Chimie BP 47
>
> 38040 GRENOBLE Cedex 9 France
>
>
>
>
> On 15/01/2014 13:37, pierre crumeyrolle wrote:
>
> bonjour,
>
> quelqu'un a t il déjà mis en place du partitionnement sur une base
> postgresql ( table de plus de 100 millions de lignes )
>
>
> cordialement
> Pierre Crumeyrolle
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>
>
>
>
> --
>
> Administrateur Systèmes et Base de données
>
> téléphone: +33 (0)4 76 63 53 89 ; fax: +33 (0)4 76 63 53 86
>
> Adresse postale:
>
> CNRS / EUROFIDAI UPS 3390
>
> 150, rue de la Chimie BP 47
>
> 38040 GRENOBLE Cedex 9 France
>
>
>
>
>