Re: Postgresql partitionnement

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] *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
> <mailto: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
> <mailto: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
>