Re: Partionnement automatique

Le 30 août 2011 16:09, Baptiste Manson
<baptiste(dot)manson(at)inovia-team(dot)com> a écrit :
> Bonjour à tous,
>
> C'est mon premier article dans cette mailing list, alors n'hésitez pas
> à me faire vos commentaires si je ne respecte pas l'étiquette.
> Nous avons écrit quelques articles sur la mise en place d'un
> partionnement automatique :
> L'idée est de fournir, pour des applications avec peu de write
> (beaucoup de read) des fonctionnalités avancées pour gérer les
> partitions et les maintenir.
> Nous avons implémenté cela avec un trigger basé sur l'INSERT et sur
> une clé fonctionnelle de partionnement.
> Voici le code de la fonction concernée :
>
> -- Attach a magic function to the insert of this table:
> CREATE OR REPLACE FUNCTION create_partition_and_insert()
> RETURNS trigger AS
> $BODY$
> DECLARE
> partition VARCHAR(25);
> BEGIN
> partition := TG_RELNAME || '_' || NEW.period || ‘p’;
> IF NOT EXISTS(SELECT relname FROM pg_class WHERE relname=partition) THEN
> RAISE NOTICE 'A partition has been created %',partition;
> EXECUTE 'CREATE TABLE ' || partition || ' (check (period = ''' ||
> NEW.period || ''')) INHERITS (' || TG_RELNAME || ');';
> END IF;
> EXECUTE 'INSERT INTO ' || partition || ' SELECT(' || TG_RELNAME || ' '
> || quote_literal(NEW) || ').*;';
> RETURN NULL;
> END;
> $BODY$
> LANGUAGE plpgsql VOLATILE
> COST 100;
> Voici un article détaillant le processus :
> http://blog.inovia.fr/auto-partitioning-on-postgresql-part-1/
>
> Quels inconvénients et avantages voyez vous sur cette méthode ?

L'avantage est le coté dynamique bien sur. Toutefois il faut pondérer.
Le dynamisme sur l'insert dans une table ou dans une autre aura un
léger impact comparé à un insert dédié pour chaque table mais impact
probablement négligeable. (et puis a l'inverse, le nombre de trigger à
déployer peut impacter si il y en a trop).
Par contre, il est tres fortement déconseillé de passer des DDL (le
create table) dans un trigger. Il y a un énorme risque d'effet boule
de neige: le temps de creer la table, d'autres INSERT risque de se
produire et de déclencher eux aussi des create table, ca s'accumule,
puis tous vont faire un rollback, sauf 1 qui va gagner (l'effet sur le
serveur est une pause dans la qualité du service) ;)
La solution consiste à avoir une partition 'fourre-tout' et des
creations de partition périodique (cron par exemple). La partition
fourre-tout sert alors lorsque la partition qui aurait du etre créée
par 'cron' ne l'a pas été et que l'on ne veut pas que le trigger
plante jusqu'a ce qu'un admin agisse.

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation