Re: Partitionement

Hello Dimitri,

Désolé de revenir sur le sujet mais comment voit on dans l'explain plan .

> clause évaluée avant la planification
> ou bien pendant l'exécution

Merci d'avance.
Pierre

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

Le 7 octobre 2013 08:46, Pierre BOIZOT <pierre(dot)boizot(at)gmail(dot)com> a écrit :

> 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
>>
>
>