Re: Postgresql partitionnement

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