Re: Partitionement

Bonjour Dimitri,

Dans ta réponse il y a un commentaire que je ne comprends pas totalement
pour ne pas dire totalement :-( .

> Afin de distinguer les deux cas (clause évaluée avant la planification
> ou bien pendant l'exécution), on utilise sans surprise EXPLAIN.

Peux tu nous en dire plus ....

​Merci d'avance.​

Pierre.

G+ <https://plus.google.com/u/0/107377830070954284209/about>

Le 6 octobre 2013 23:56, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> a écrit :

> Pierre BOIZOT <pierre(dot)boizot(at)gmail(dot)com> writes:
> > Il s'avere que l'écriture de la clause CHECK est importante ....
>
> Très importante en effet.
>
> > CREATE TABLE sales_part1
> > (CHECK (org = 6 and temps between to_date('20101001'::text,
> > 'yyyymmdd'::text) and to_date('20131001'::text, 'yyyymmdd'::text)) )
> > INHERITS (sales);
>
> > ​CREATE TABLE ventes_part1
> > (CHECK ( (temps >= date '20101001' and temps <= date '20131001')
> > and org=6 ) )
> > INHERITS (ventes);​
>
> La contrainte CHECK et la clause WHERE doivent être démontrées
> incompatibles par le plannificateur de requêtes pour bénéficier du
> paramétrage qui t'intéresse.
>
> La première écriture utilise un appel de fonction qui sera réalisé par
> l'exécuteur de requête, bien après la phase de planification. La seconde
> écriture utilise la notation dite de « litéral décoré » qui elle est
> résolue au moment de la lecture (parsing) de la requête, avant que le
> planificateur entre en jeu.
>
> Afin de distinguer les deux cas (clause évaluée avant la planification
> ou bien pendant l'exécution), on utilise sans surprise EXPLAIN.
>
> > En conclusion ....
> > Cela marche mais il est impératif d'éxaminer soigneusement la requete la
> > clause CHECK des tables.
>
> Non seulement la clause CHECK, mais égalemment l'écriture des clauses
> WHERE.
>
> > *Question subsidiaire* : il me semble avoir lu dans la documentation que
> > l'on ne devrait pas aller au delà de 100 partitions.
> >
> > Est-ce encore d'actualité ?
>
> Les caractéristiques de performances de l'algorithme qui prouve (au sens
> de preuve mathématique) l'incompatibilié des clauses CHECK et WHERE
> dépendent fortement du nombre de clauses à évaluer. Le chiffre est à
> valider dans ton environnement et pour tes clauses plutôt qu'à prendre
> au pied de la lettre, mais l'ordre de grandeur est certainement à garder
> à l'esprit.
>
> Si par conception tu sais que tu devras gérer plusieurs milliers de
> partitions, sache que c'est à tester en détails avec le bon nombre de
> partitions et des données conséquentes avant de partir en production.
>
> --
> Dimitri Fontaine
> http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
>