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

SQLpro · 10/10/2011, 02h31

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

scheu · 11/10/2011, 10h35

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

SQLpro · 11/10/2011, 11h41

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 +

scheu · 11/10/2011, 15h29

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

SQLpro · 11/10/2011, 15h50

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

A +

10/10/2011, 02h31	#1
SQLpro Rédacteur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 12 074 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 12 074 Points : 21 669 Points : 21 669	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 __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

11/10/2011, 10h35	#2
scheu Membre Expert Inscription : juin 2007 Messages : 1 501 Détails du profil Informations forums : Inscription : juin 2007 Messages : 1 501 Points : 1 493 Points : 1 493	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 __________________ La théorie, c'est quand on sait tout mais que rien ne fonctionne. La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi ! Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/
	00

11/10/2011, 11h41	#3
SQLpro Rédacteur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 12 074 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 12 074 Points : 21 669 Points : 21 669	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 + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

11/10/2011, 15h29	#4
scheu Membre Expert Inscription : juin 2007 Messages : 1 501 Détails du profil Informations forums : Inscription : juin 2007 Messages : 1 501 Points : 1 493 Points : 1 493	Bien sûr, pas de droits d'auteur entre nous ! __________________ La théorie, c'est quand on sait tout mais que rien ne fonctionne. La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi ! Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/
	00

11/10/2011, 15h50	#5
SQLpro Rédacteur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 12 074 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 12 074 Points : 21 669 Points : 21 669	Un coup à boire un de ces soirs alors.... A + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email