Nouvel article : comparaison des solutions de partitionnement PostGreSQL/SQL Server

A lire : http://blog.developpez.com/sqlpro/p1...araison-postg/

Contenu :

1 - LE PRINCIPE DU PARTITIONNEMENT
2 - L'EXEMPLE
3 - TECHNIQUE DU PARTITIONNEMENT
3 - LA SOLUTION POSTGRESQL
PARTITIONNEMENT DE TABLE version PostGreSQL - PREMIÈRE CONCLUSION
4 - LA SOLUTION MS SQL SERVER
PARTITIONNEMENT DE TABLE version MS SQL Server - PREMIÈRE CONCLUSION
5 - MANIPULER LES DONNÉES D'UNE TABLE PARTITIONNÉE
5.1 - les insertions
5.2 - Les extractions
5.3 - Les suppressions
5.4 - les modifications
6 - LA VIE D'UNE TABLE PARTITIONNÉE
6.1 - ajouter un index
6.2 - Ajouter une colonne
6.3 - Ajout d'une clef
6.4 - Ajout d'une contrainte de validation
6.5 - Ajout d'une contrainte d'intégrité
7 - PARTITIONNEMENT MULTICOLONNE
8 - CONCLUSION PARTITIONNEMENT PostGreSQL vs MS SQL Server

Vos avis, vos commentaires seront appréciés.

Merci

:ccool:
Très intéressant et très complet ton article
Le peu que j'avais testé du partitionnement sous Postgresql m'avait amené à la même conclusion que toi : une usine à gaz difficile à maintenir et impensable dans un environnement de production

Pour compléter ton article, tu aurais aussi pu parler des performances en insertion : j'avais fait il y a quelques années un bench entre Oracle 10g et Postgresql 8.2, et pour une boucle d'insert ligne à ligne dans une table partitionnée, c'était 2 fois plus long sous Postgresql (sans doute à cause de tous les triggers et contraintes à vérifier à chaque insert)
Ca pourrait être intéressant de comparer les temps entre Postgresql et SQL Server

Egalement pour aller plus loin sur les plans d'exécution, sous Postgresql pour que le plan d'exécution ne lise que la bonne partition (et pas toutes les autres), il faut faire un filtre direct sur la table (ex : "where col_date = '2010-01-05'").
Mais dès l'instant où le filtre sur ta clé de partitionnement est issu d'une condition de jointure, ça ne marche pas la plupart du temps, et Postgresql parcourt toutes les partitions.
Exemple avec "table1" partitionnée par mois sur col_date et une requête du style "where table1.col_date = table2.col_date and table2.col_date = '2010-01-05'" : Postgresql 8.2 parcourt toutes les partitions de "table1" et non pas seulement celle correspondante à janvier 2010
Alors qu'Oracle (et aussi SQL Server j'imagine) est capable par association d'en déduire table1.col_date='2010-01-05' et de ne lire que la partition de janvier 2010
J'ai rencontré plusieurs fois ces problèmes de mauvais plans d'exécution en Postgresql 8.2, je n'ai pas testé si c'était toujours le cas dans les dernières versions

Très bon article en tout cas ;)

Peut tu.. ou puis-je... mettre tes judicieuse remarques directement dans l'article ? ça aidera d'autres personnes qui mettent en place cela dans PG...

A +

Bien sûr, pas de droits d'auteur entre nous ! :mouarf:

Un coup à boire un de ces soirs alors....

A +